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The  Integrated  Modular  Persistent  Object  Representation 
Translator  (IMPORT)  is  a  programming  language  devel¬ 
oped  as  part  the  Integrated  Systems  Language  Environ¬ 
ment  (ISLE),  and  intended  to  provide  software  engineer¬ 
ing  support  for  modeling  and  simulation  of  complex 
ecological  systems  such  as  the  modem  battlefield. 

IMPORT  integrates  a  number  of  software  technologies: 
object-oriented  imperative  programming,  knowledge- 
based  declarative  programming,  process-based  simula¬ 
tion,  and  persistent  object  storage. 


IMPORT  manages  programs  as  data,  like  a  CAD  system 
manipulates  design  artifacts.  It  is  implemented  as  an 
objer^-oriented  framework  that  models  the  language  and 
supports  persistent  object  storage  of  an  intermediate 
representation  in  the  form  of  abstract  syntax  trees, 
syndMl  tables,  and  associated  structures.  The  parser 
translates  input  into  this  intermediate  representation,  arxl 
subsequent  operations  on  these  artifacts  occur  through 
the  classes  of  the  framework.  Facilities  for  editing, 
browsing,  compiling,  version  control,  interpreting/debug¬ 
ging,  optimizing,  code  generating,  and  profiling  are 
provided  based  on  the  framework.  This  report  defines  the 
language,  describes  its  impiementation,  and  outlines  re¬ 
search  directions  within  the  context  of  the  project. 
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DEFINITION  AND  IMPLEMENTATION  OF  THE  INTEGRATED 
MODULAR  OBJECT  REPRESENTATION  TRANSLATOR  (IMPORT) 


1  INTRODUCTION 


Background 

Scientific  and  engineering  disciplines,  from  computer  science  to  operations  research,  have  long  used 
computer  simulations  to  develop  models  that  help  analysts  understand,  predict,  and  control  complex 
systems.  Over  time,  a  large  body  of  knowledge,  methodologies,  and  software  tools  have  been  developed 
for  dotiiain  specifics  and  to  meet  general  purpose  needs.  These  approaches  typically  rely  on  the 
qiplication  of  a  single  software  technology,  such  as  imperative  programming,  to  derive  a  software  system 
the  sole  function  of  which  is  simulation.  This  approach  has  beat  effective  for  simulation  of  isolated 
systems. 

Over  the  past  two  decades,  many  efforts  have  been  made  to  develop  large-scale  simulations  spanning 
many  levels  of  system  resolution,  e.g.,  the  combat  models  developed  by  operations  researchers  in  support 
of  defense  requirements  (Davis  and  Huber  1992).  These  efforts  to  develop  simulations  of  large  parts  of 
reality  have  used  most  software  technologies  and  techniques  (Herring,  Wallace,  and  Whitehurst  1991). 
For  example,  declarative  programming  is  typically  used  to  model  human  decisionmaking,  while,  for 
efRciency,  static  portions  of  models  are  written  in  imperative  languages.  However,  most  expert  system 
shells  are  designed  as  standalone  packages,  providing  only  external  interfaces  to  other  programming 
systems.  Other  similarly  designed  software  technologies  cannot  address  modeling  and  simulation  in  a 
consistent  and  integrated  manner.  Recent  Advanced  Research  Projects  Agency  (ARPA)  and  Department 
of  Defense  (DOD)  initiatives  have  expressed  goals  far  beyond  the  use  of  analytical  simulations  as 
single-user  tools  (DA  1992,  Director  of  Defense  Research  and  Engineering  1992a,  1992b).  These 
initiatives  have  piloted  research  cm  Distributed  Interactive  Simulation  (DIS)  to  use  virtual  reality  for 
training,  hardware  prototyping  and  evaluation,  as  well  as  for  analytical  purposes. 

In  recognition  of  the  trend  toward  object-oriented  programming  and  its  appropriateness  for  modeling 
and  simulatirm,  the  U.S.  Army  sponsored  the  develojanent  of  an  object-oriented  programming  language 
fcH*  simulation.  In  1988,  this  project  began  to  investigate  the  integration  of  modem  software  and  hardware 
architectures  to  support  large-scrde  simulation.  This  resulted  in  die  U.S.  Army  ModSim,  Version  1.0,  the 
modular  simulation  language  (Herring  1990).  ModSim  is  a  general-purpose  fully  object-oriented 
programming  language  based  on  Modula-2,  which  provides  strong  typing  and  modularity  for  programming 
in  the  large  (Wirth  1984).  ModSim  also  provides  an  object  data  type  and  integrates  process-based 
discrete-event  simulation  with  objects.  Methods  of  objects  are  asynchr  onous  threads  of  execution  and  the 
language  provides  primitives  for  passing  simulation  time  and  for  synchronization. 

As  a  research  test  bed,  a  combat  model  was  developed  using  ModSim  to  experiment  with  the 
application  of  software  technologies  and  techniques.  The  Model-View-Controller  framework  of 
SMALLTALK  (Krasner  1988)  was  used  as  a  guitte  to  designing  both  the  global  and  local  architecture  of 
the  model.  From  a  study  of  existing  models  and  knowledge  of  emerging  software  capabilities,  two 
requirements  became  evident:  (1)  the  need  for  declarative  programming  to  model  complex  decision¬ 
making,  and  (2)  the  need  for  consistent  object  storage  for  model  management  Work  on  these 
requirements  resulted  in  the  ModLog  (modular  logic)  declarative  programming  language  (Whitehurst  1991, 
19%),  and  Persistent  ModSim  (Herring  1991,  1993). 
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Based  on  experience  with  these  two  languages,  and  with  other  |nt>totypes  during  applications 
development,  a  new  language  was  designed  and  implemented  to  provide  full  integraticHi  of  the  software 
technologies  identified  to  support  general  modeling  and  simulation,  the  IMPORT/DOME  language  system. 
IMPORT/DOME  is  one  of  a  number  of  tools  that  comprise  the  Integrated  Simulation  Language 
Environment  (ISLE).  The  tools  in  the  ISLE  environment  interact  with  the  persistent  object  repository, 
which  stores  information  about  the  class  hierarchy,  the  programs  under  development,  and  the  results  of 
program  execution — all  at  the  object-level  of  granularity  (as  opposed  to  the  file,  or  fiirKtion-level  granu¬ 
larities  that  exist  in  most  systems).  All  the  tools  in  ISLE  interact  with  the  object  repository  and  operate 
from  the  intermediate  form  of  IMPORT/DOME  programs. 


Objective 

The  objective  of  this  work  was  to  develop  an  integrated  application  of  an  object-oriented,  imperative 
and  declarative  programming  language  that  combined  process-based  discrete-event  simulaticm  and  per¬ 
sistent  object  storage  to  address  large-scale,  complex  systems  modeling  and  simulation. 


Approach 

IMPORT  is  a  direct  descendent  of  ModSim,  and  Persistent  ModSim  is  a  declarative  language 
extension  to  ModSim,  based  on  PROLOG,  which  is  a  language  developed  for  theorem  proving  and 
artificial  intelligence  applications.  Persistent  ModSim  differs  from  PROLOG  in  that  it  was  intended  to 
provided  intelligent  decisionmaking  support  to  objects  while  embedded  in  a  simulation;  it  is  designed  for 
solving  problems  that  involve  objects  and  the  relatitxnships  between  objects.  The  Persistent  ModSim 
extension  to  ModSim  consists  of  a  language  for  specifying  declarative  rule  bases,  an  object-oriented 
interpreter  for  the  language  that  can  be  inherited  by  objects,  and  a  facility  for  “binding”  knowledge-base 
objects  to  the  imperative  objects  in  the  simulation. 

Persistent  ModSim  is  a  version  of  ModSim  integrated  with  a  commercial  object-oriented  database. 
The  approach  taken  to  provide  ModSim  with  persistent  object  storage  capabilities  was  quite  straightfor¬ 
ward.  Two  changes  were  required  in  the  syntax;  (1)  the  NEWOBJ  primitive  was  extent^  to  include  an 
optional  second  parameter,  which  is  an  object  reference  to  a  database,  conflguration,  or  segment  This 
permits  specification  of  object  instance  allocation  in  the  persistent  object  store;  (2)  a  TRANSACTION 
statement  was  introduced  to  provide  for  short  term  database  transaction  management  This  was  necessary 
to  provide  multi-user  access  to  the  same  database  files.  Next  a  set  of  classes  were  developed  to  provide 
access  to  the  underlying  database  functionality,  including;  database,  database  root  collection, 
configuration,  workspace,  and  segment.  As  the  object-oriented  database  supports  a  C  language  library 
interface  and  is  implemented  as  a  translator  to  C,  minor  changes  in  the  C  c^e  generation  provide  for 
interfacing  to  the  database. 

IMPORT  differs  significantly  from  ModSim  in  that  it  was  specifically  designed  for; 

1.  A  higher  degree  of  integration  and  consistency  with  the  syntax  and  semantics  of  the  declarative 
complementary  language. 

2.  EnhaiKement  of  the  language  with  new  constructs  and  removal  of  those  deemed  utmecessary. 

3.  An  implementation  based  on  the  persistent  object  repiository,  providing  for  storage  of  the 
intermediate  object  representation  and  versioning. 
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IMPORT  (Hovides  for  intennodule-type  definition  visibility,  and  is  integrated  in  several  ways:  (1)  it 
provides  for  the  integrated  application  of  object-orient«l  imperative  programming  and  process-based 
simulation  as  in  the  model;  (2)  it  is  integrate^  with  DOME  (as  described  below);  (3)  it  is  integrated  in  its 
unique  implementation,  which  provides  fur  Jhe  development  of  an  integrated  set  of  software  engineering 
support  tools.  IMPORT  has  four  modUie  types:  it  separates  interface  specification  and  implementation, 
for  the  INTERFACE  module  type  tur  interfacing  to  other  languages,  and  the  KNOWLEDGE  module  for 
integratitm  with  DOME. 


Mode  of  Technu'ogy  Transfer 

U.S.  Army  ModSim,  Version  1.0  has  been  distributed  to  Government  agencies  and  their  contractors 
along  with  a  suite  of  example  programs  that  aid  in  uiulerstanding  the  process-based  simulation  model  of 
ModSim  and  general  object-oriented  programming,  as  well  a  graphical  class-hierarchy  browser  and  an 
editing/compilation  management  enviroiunent.  It  is  anticipated  that  the  completed  program  may  be 
distributed  cooperatively  through  several  partiepating  agetKies:  the  Army  Material  Systems  Analysis 
Agency,  the  Defense  Logistics  Agency,  and  through  contractors  on  the  Advanced  Research  Project 
Agency's  next  generation  Distributed  Interactive  Simulation  (DIS)  War  Breaker  (Booze-Allen-Hamilton, 
Science  A|q)lications  International  Corporation,  and  The  Applications  Science  Corporation). 
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2  LANGUAGE  DEFINITION 


This  definition  of  the  IMPORT  language  is  provided  for  those  who  wish  to  study  the  details  of  the 
language,  primarily  tlK>se  interested  in  evaluating  it  for  use  or  as  a  referrace  for  programming.  A  nK>re 
compact  syntactic  descriptiem,  known  as  a  context  free  grammar,  is  given  in  Appendix  A. 


Introduction 

IMPORT  retains  the  DEFINITION  and  IMPLEMENTATION  modules  of  its  predecessors,  but  has 
the  two  new  module  types:  the  KNOWLEDGE  module  and  the  INTERFACE  module.  The  KNOWL¬ 
EDGE  module  is  an  apfHxiach  to  providing  a  more  consistent  integration  between  IMPORT  and  IX)ME. 
It  contains  the  declarative  programming  language  statements  of  DOME  as  QUERY  methods  and  relates 
them  to  IMPORT  objects  defined  in  DEFINITION  modules  and  to  the  method  bodies  that  are  located  in 
IMK-EMENTATION  modules.  The  LIST  type  permits  passing  parameters  between  the  IMPORT  and 
DOME  languages.  Enumeration  type  variables  are  also  parameters  to  DOME  QUERY  methods. 

ModSim  introduced  the  ASK  and  TELL  methods.  TELL  methods  are  asynchronous  and  have  time¬ 
passing  statements  (such  as  WATT  DURATION),  whereas  ASK  methods  are  synchronous  and  cannot  have 
simulati<Hi  time  passing  statements.  IMPORT  removes  the  restriction  chi  ASK  methods.  If  they  have 
time-passing  statements,  they  will  be  synchronous,  that  is,  the  program  will  wait  for  their  completion. 
This  permits  passing  parameters  by  reference  to  ASK  methods.  QUERY  methods  appear  in  object 
definitions  just  as  the  imperative  methods.  IMPORT  extends  object  methods  over  ModSim  in  a  number 
of  ways.  There  are  OPERATOR  methods  providing  for  operate  overloading.  (All  methods  may  have 
overloaded  signatures  with  the  exception  of  DESTRUCTOR  methods.)  Additicmally,  overloaded 
CONSTRUCTOR  methods  may  be  specified  through  extended  syntax  of  the  NEW  {vimitive. 

The  following  have  been  removed  from  IMPORT:  records,  procedures,  pointers,  and  subrange 
types.  The  removal  of  procedures  caused  the  MAIN  module  ccmstruct  for  specifying  the  starting  point 
of  an  2^plicati(Hi  to  become  inconsistent,  so  it  was  replaced  by  the  KEY  statement,  which  is  used  to 
specify  applications.  The  KEY  specifies  an  object  to  he  created,  and  a  method  of  the  object  that  Iwill 
be  the  entry  point  of  the  {plication.  KEYs  are  used  by  the  interpreter  and  code  generator  to  determine 
the  modules  and  objects  involved  in  an  qtplicatitm.  A  KEY  statement  has  the  form: 

KEY  keyjuime 

FROM  modulejiame  CREATE  class jume 

INVOKE  method  name  (arguments). 

Persistoice  in  IMPORT  is  achieved  as  in  Persistent  ModSim  through  overloading  the  NEW  function 
and  providing  a  set  of  classes  that  model  a  generic  object-oriented  database  c^bility. 

There  are  other  minor,  but  convenient  changes.  For  example,  the  language  is  case  insensitive  to 
keywmxls,  and  identifiers  cannot  be  keywords.  The  familiar  C  shorthand  assignment  operators  (+=,  -=, 
etc.)  are  supported. 
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Deffnition  of  Terms 


Tlie  following  description  uses  conventional  tenninology.  A  variable  is  a  place  tM)lder  or  location 
for  the  result  of  a  computation.  The  result  of  a  comimtation  must  have  a  defii^  domain,  called  a  type. 
Variables  must  also  have  type,  and  can  only  hold  values  within  that  domain. 

An  identifier  is  a  symbol  declared  as  a  name  for  a  variable,  a  type,  a  constant,  a  class,  etc.  The 
scope  of  a  declaration  is  the  region  over  which  a  declaration  has  effect  IMPORT  is  a  lexically  scoped 
language.  An  expression  specifies  a  computation  which  produces  a  vaiue.  The  teim  repository  refers  to 
the  object-orient^  database  and  associate  schemas  used  to  store  IMPORT  modules. 


Modules 

The  highest  level  of  abstraction  characterizing  IMPORT  is  the  module.  An  IMPORT  af^lication 
is  a  collection  of  modules  and  a  key.  There  are  four  types  of  modules;  DEFINITION  modules, 
IMPLEMENTATION  modules,  KNOWLEDGE  modules,  and  INTERFACE  modules. 

Each  LviPLEMENTATION  module,  KNOWLEDGE  module,  and  INTERFACE  module  must  have 
a  corresponding  DEFINITION  module  of  the  same  name.  We  may  refer  to  these  three  modules 
collectively  as  implementation  modules.  Each  DEFINITION  module  must  have  either  an  IMPLEMENTA¬ 
TION  module,  or  a  KNOWLEDGE  module,  or  an  INTERFACE  module  or  any  combination  of  the  three. 
The  relation  of  modules  in  IMPORT  is  shown  in  Figure  1. 

The  declarations  and  IMPORTS  made  in  a  DEFINITION  module  are  autmnatically  included  into  the 
corresponding  IMPLEMENTATION,  KNOWLEDGE,  and  INTERFACE  modules. 


Figure  1.  Relationships  of  IMPORT  Modules. 
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DEFINITION  Modules 


A  DEPlNmON  module  ccmtains  type  and  class  definitions.  It  also  contains  any  global  constants 
that  may  be  used  in  implementation  modules.  These  modules  defme  the  interface  to  be  used  with  the 
implementation  modules. 

Data  sharing  between  modules  is  achieved  via  an  IMPORT  statement,  which  is  described  in 
Statements,  p  18. 

A  DEFINITION  module  has  the  following  form: 

DEFINITION  MODULE  module_name; 

IMPORT  statements 

type,  constant  and  class  definition  list 
END  MODULE. 

IMPLEMENTATION  Modules 

IMPLEMENTATION  modules  contain  the  implen^ntation  and  body  of  the  classes  defined  in  the 
DEFINITION  module.  These  classes  contain  imperative  (procedural)  code. 

An  IMPLEMENTATION  module  has  the  following  form: 

IMPLEMENTATION  MODULE  module  jiame; 

IMPORT  statements 

class,  imperative  and  declarative  code 
class2  imperative  and  declarative  code 

class,,  in^erative  and  declarative  code 
END  MODULE. 

KNOWLEDGE  Modules 

KNOWLEDGE  modules  contain  the  initial  state  of  the  knowledge  base  for  each  class.  A 
KNOWLEDGE  module  may  not  have  IMPORT  statements  in  it  KNOWLEDGE  modules  are  written  in 
the  DOME  (teclarative  language  and  are  interpretively  executed  at  runtime.  The  KNOWLEDGE  module 
has  the  form: 

KNOWLEDGE  MODULE  modulejiame; 
class,  knowledge  base  definition 
class2  knowledge  base  definition 

class,,  knowledge  base  definition 
END  MODULE. 

INTERFACE  Modules 

INTERFACE  modules  provide  a  mechanism  to  interface  with  existing  code  bodies.  Currently  the 
implementation  supports  C  and  C++,  but  it  can  readily  be  extended  to  other  languages.  Through  this 
facility  the  programmer  can  “wrapper”  existing  C  library  functionality  into  an  IMPORT  class  and  make 
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use  of  these  classes  as  if  the  implementation  was  in  IMPORT.  That  is,  there  are  no  restrictions  on 
inheritance  and  polymorfriiism. 


INTERFACE  MODULE  modulejume; 
IMPORT  statements 

external _class,  language  specific  renaming 
external  classj  language  specific  renaming 

external _class^  language  specific  renaming 
END  MODULE. 


Keys 


The  key  statement  is  used  to  specify  24)plications.  The  key  specifies  an  object  to  be  created,  and 
a  method  of  that  object  that  will  be  the  entry  point  of  the  applicatitm.  There  may  be  any  number  of  keys 
related  to  the  IMPORT  modules  in  a  repository.  Keys  are  stored  in  the  repository  with  the  corresponding 
modules.  Keys  are  used  by  the  interpreter  and  code  generator  to  determine  the  modules  and  objects 
involved  in  an  application. 

The  key  statement  may  be  put  in  a  separate  file,  or  within  a  file  ctHitaining  a  DEFINITION 
MODULE  or  an  IMPLEMENTATION  MODlAf.  If  it  occurs  within  such  a  file,  it  must  occur  outside 
the  MODULE-END  MODULE  block.  A  key  must  be  given  a  unique  name  within  die  repository  where 
the  suite  of  modules  resides.  A  key  declaration  has  die  form: 

KEY  key_name: 

FROM  module  juune  CREATE  class  jiame  INVOKE  methodjuune  (arguments). 


Types 

IMPORT  uses  name  equivalence  to  determine  types.  The  rally  nraiatomic  types  that  IMPORT 
allows  are  arrays,  classes,  and  lists.  Every  expression  has  a  statically-determined  type. 

Assignability  and  type  compatibility  is  discussed  in  the  individual  subsections.  Unless  specifically 
allowed,  types  are  generally  not  assignment  compatible. 


Ordinal  Types 

There  are  two  ordinal  types:  enumerations  and  integers.  An  enumeratirai  type  is  declared  as  follows: 

TYPE  T  =  {id„  id, . Id,}; 

In  this  case,  id,  will  have  an  integer  value  of  0,  ufj  a  value  of  1,  and  id,  a  value  of  n-1. 

The  operators  ORD  and  VAL  convert  between  enumeratira)  types  and  integers.  In  addition,  the 
predicate  ODD  returns  TRUE  when  the  value  of  an  ordinal  is  o^  INC  and  DEC  increment  and 
decrement  the  value  of  an  ordinal  respectively. 

The  identifiers  id„  idj,  etc.  can  be  used  to  index  arrays,  and  are  compatible  with  integers  in 
relational  operations,  but  not  arithmetic  operations  or  odierwise. 
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There  are  two  predefined  enumerated  types:  BOOLEAN,  which  is  the  enumeratiiHi  ( TRUE,  FALSE } 
and  CHAR,  which  is  an  enumeratitm  of  256  elements,  generally  the  character  set  of  the  implementation. 
CHR  is  defined  rm  integers  and  converts  an  integer  into  the  appropriate  character. 

The  elements  of  tte  enumeraticms  must  be  distinct.  Declaraticms  of  the  form: 

TYPE  CITRUS-FRUITS  =  (ORANGE,  GRAPEFRUIT,  LEMON); 

TYPE  BREAKFAST  =  (MILK,  GRAPEFRUIT,  TOAST,  EGGS); 

are  not  allowed,  since  GRAPEFRUIT  appears  twice.  If  they  are  in  different  modules,  however,  they  can 
be  renamed  to  be  distinct  with  the  IMPORT  statement 

Floating  Point  Types 

At  the  present  time,  there  is  cme  floating  point  type  REAL.  The  basic  arithmetic  and  relational 
operators  apply  to  REALs. 

The  following  built-in  functions  triply  to  REAL  data-type: 

FLOAT  (0  Converts  INTEGER  to  REAL. 

TRUNC  (r)  Truncates  a  REAL  into  an  INTEGER. 


Strings 

STRINGS  are  defined  as  a  first-class  data-type  in  IMPORT.  The  STRING  stores  characters  and  is 
automatically  and  dynamically  allocated  and  reallocated.  STRINGS  are  indexed  from  0  as  are  aU  arrays 
in  IMPORT.  However,  STRINGS  are  not  indexable  via  the  []  operator  as  are  arrays. 

The  following  built-in  functions  apply  to  STRINGS*. 


CHARTOSTR  (c) 

INTTOSTR  (0 
LOWER  (str) 

POSITION  (srr,,  stTj) 
REALTOSTR  (r) 

SCHAR  istr,  pos) 

STRCAT  (j/r„  strj, ....  str^ 

STRLEN  istr) 

STRPUT  (org,,  arg^ . arg^ 


Converts  CHAR  into  STRING. 

Converts  INTEGER  into  STRING. 

Returns  a  STRING  with  all  lower  case  letters. 

Returns  the  position  of  s/Tj  in  str,. 

Converts  REAL  into  STRING. 

Returns  the  CHAR  at  positicHi  pos  in  str. 

Produces  a  new  STRING  which  is  a  concate¬ 
nation  of  all  die  STRINGS  s/r„  stTj . str^. 

Returns  die  length  of  the  STRING. 

Qmverts  all  the  arguments  arg„  argi, . . . , 
org,  into  STRINGS  and  concatenates  them 
together. 

Converts  STRING  into  INTEGER. 

C!onverts  STRING  into  REAL. 


STRTOINT  istr) 
STRTOREAL  istr) 
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SUBSTR  ^pos^,  pcs2,  str) 
UPPER  (str) 


Returns  the  substring  from  posi  to  posj. 
Returns  a  STRING  with  all  upper  case  letters. 


The  following  built-in  procedures  apply  to  STRINGs: 


INSERT  (sir,,  pos,  str^  Inserts  s/Tj  into  sir,  at  pos. 

REPLACE  (sir,,  pos,,  posj,  sITj)  Replaces  the  part  of  sir,  from  pos,  to  posj 

wiA  SlTj. 

STRTOCHAR  (sir,  array  of _char)  Converts  a  STRING  into  an  ARRAY  OF 

CHAR.  The  size  of  the  ^uray  must  be 
sufficient. 

Arrays 

An  array  is  an  indexed  collection  of  elements  of  a  given  type.  Indices  to  an  array  must  be 
expressi(Mis  of  INTEGER  type  or  an  enumerated  type.  All  array  indices  start  at  0,  and  if  die  size  of  an 
array  is  n  then  the  maximum  addressable  element  is  n-1.  Multidimensional  arrays  are  allowed. 


Examples: 

TYPE  MY.ARRAY  =  ARRAY  [20]  OF  INTEGER; 

TYPE  NAME.ARRAY  =  ARRAY  [20]  OF  ARRAY  OF  [10]  OF  CHAR; 

The  first  declaratitm  is  of  a  one-dimensicmal  array  of  INTEGERS  and  the  second  a  two-dimensimial 
array  of  ClHARs. 

If  an  array  A  is  of  type  T,  then  A[{],  where  i  is  an  integer,  is  the  rth  element  of  A.  Array  names 
may  not  be  used  in  comparisons  or  arithmetic  operations. 

Lists 


The  LIST  type  is  supplied  to  provide  for  integraticm  of  imperative  IMPORT  methods  and  the  DOME 
declarative  methods.  A  list  is  an  ordered  collection  of  heterogeneous  elements.  The  elements  may  be  of 
any  type.  An  empty  list  is  denoted  by  NULL. 

The  following  operations  are  defined  on  lists; 

HEAD  (list)  Returns  the  element  at  the  head  of  the  LIST. 

TAIL  (list)  Returns  the  LIST  starting  at  the  second  element 

APPEND  (listi,  list2)  Creates  a  new  LIST  from  /wl,  and  /isij  and  returns  it 

NTH  (int,  list)  Returns  the  nth  element  of  the  list. 

LENGTH  (list)  Retims  the  length  of  the  list. 
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Objects 


An  object  is  either  NULL  or  an  instance  of  its  class.  The  class  of  an  object  defines  an  object’s 
members.  There  are  three  types  of  members:  data  members  (or  fields),  imperative  methods,  and 
declarative  methods.  The  field  and  methods  of  an  object  are  defined  in  die  DEFINITION  module.  The 
imperative  methods  are  contained  in  the  IMPLEMENTATION  or  INTERFACE  modules,  and  the 
declarative  methods  (or  knowledge-base)  are  contained  in  the  KNOWLEDGE  module. 

The  values  of  data  members  constitute  the  state  of  an  object.  The  state  of  an  object  can  only  be 
changed  by  the  methods  of  the  object.  A  method  is  a  body  of  imperative  or  declarative  code,  which  may 
or  may  not  alter  the  state  of  an  object 

A  declaration  of  a  class  in  the  DEFINITION  module  has  the  form: 

TYPE  identifier  =  OBJECT  (superclassi,  superclass^, ....  superclass,^ 
field  and  method  list 
PRIVATE 

field  and  method  list 
OVERRIDE 

field  and  method  list 
END  OBJECT; 

Only  the  method  prototypes  are  listed  in  the  declaraticm.  The  actual  methods  are  defined  in  the 
IMPLEMENTATION  module.  The  IMPLEMENTATION  module  contains  the  method  bodies  for  each 
class: 


OBJECT  classy, 
methodi 
method^ 

method^ 

END  OBJECT 

In  the  ct^  of  the  INTERFACE  module,  the  language  specific  renaming  of  objects,  fields,  and 
methods  is  given  for  code  generation  compatibility  purposes.  The  use  of  the  extended  syntax  for  renaming 
is  illustrated  below.  The  AS  key  ori  is  used  to  specify  the  name  of  an  external  object,  field,  or  method. 
The  STATIC  key  word  is  used  to  indicate  a  C-H-  static  or  class  member.  AS  and  STATIC  may  be 
combined. 

OBJECT  class ^  AS  c++_c/asj_name,; 
fieldi  AS  C++  Jieldjuimei; 
methodi  AS  c++_method_name{; 
method^  STATIC; 

method-  AS  C++  method  name-  STATIC; 

END  OBJECT 

Data  Members.  The  fields  of  an  object  are  declared  as  follows: 
idi,  id^,...,  id„:  type; 
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Within  each  method,  instance  variables  of  the  object  may  be  accessed  as  if  they  were  variables  in 
the  local  scope.  Data  members  of  super  classes  may  also  be  accessed  in  this  manner.  Beyond  the  scope 
of  the  class,  methods  of  other  instances  may  obtain  a  value  of  an  instance  variable  through  an  ASK 
method  invocation  of  the  form: 

ASK  objjume  id^ 
which  will  return  the  value  of  id^. 

These  methods  are  automatically  defmed  when  the  data  members  of  a  class  are  defined.  In  addition, 
a  member  SELF  is  automatically  defined  for  each  class,  and  always  contains  the  identity  of  the  instance. 
This  member  may  not  be  assigned  to. 

Methods.  There  ate  six  types  of  methods:  CONSTRUCTOR  methods,  DESTRUCTOR  methods, 
ASK  methods,  TELL  methods,  QUERY  methods,  and  OPERATOR  methods.  With  exception  of  the 
DESTRUCTOR  method,  methods  may  be  overloaded  as  long  as  signatures  can  be  distinguished. 

The  arguments  to  these  methods  may  be  passed  by  value,  or  by  reference.  Each  parameter  must  be 
declared  either  to  be  IN  (arguments  to  be  passed  by  value),  OUT,  or  INOUT  (arguments  to  be  passed  by 
reference). 

CONSTRUCTOR  methods  are  automatically  invoked  when  an  object  instance  is  allocated. 
CONSTRUCTOR  methods  may  be  overloaded,  but  may  not  specify  a  return  value.  The  CONSTRUCTOR 
method  for  an  object  is  always  named  Objinit  A  CONSTRUCTOR  method  prototype  looks  like: 

CONSTRUCTOR  METHOD  Objinit  (IN  param^); 

DESTRUCTOR  methods  are  automatically  invoked  when  an  object  instance  is  deallocated.  Only 
one  DESTRUCTOR  method  may  be  defined  per  class,  and  it  may  have  no  arguments  and  may  return  no 
value.  It  is  always  named  ObjTerminate.  A  DESTRUCTOR  method  prototype  looks  like: 

DESTRUCTOR  METHOD  ObjTerminateO; 

ASK  methods  are  synchronous  bodies  of  imperative  code  and  may  be  used  in  expressions.  They 
may  return  a  value,  and  may  contain  all  three  kinds  of  parameters:  IN,  OUT,  and  INOUT.  An  ASK 
method  prototype  looks  like: 

ASK  METHOD  methodjume  (IN  paramo’.  INTEGER,  INOUT  param2,param^ :  REAL) :  REAL; 

The  method  defmed  takes  three  arguments  and  returns  a  REAL. 

TELL  methods  are  asynchronous  bodies  of  imperative  code:  in  the  current  implementation  a  separate 
light-weight  process  is  created  for  them,  and  there  is  no  guarantee  on  order  of  evaluation.  As  a  result, 
they  are  not  allowed  to  return  any  value,  and  may  only  have  IN  parameters.  For  more  information  on  the 
interaction  of  methods,  see  Simulation  Environment,  p  32. 

TELL  METHOD  methodjiame  (IN  paramx  :  REAL); 

QUERY  methods  are  synchronous,  and  may  not  advance  simulation  time.  They  serve  as  the 
interface  to  the  Theorem  prover,  and  are  always  BOOLEAN  functions.  There  is  no  restriction  on  the  types 
of  parameters.  For  mote  information,  see  The  Theorem  Prover,  p  26. 
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QUERY  METHOD  methodjtame  (INOUT  param^  :  BOOLEAN; 


OI^RATOR  methods  are  the  mechanism  by  which  the  programmer  may  overload  arithmetic, 
relational,  and  assignment  operators.  They  must  be  binary  functions,  taking  two  arguments  of  the  same 
type:  the  class  on  which  tlK  OPERATOR  is  defined.  It  must  also  return  an  instance  of  the  same  class. 
The  arguments  are  passed  by  value.  The  operator  to  be  overloarted  is  given  as  die  methodjuune. 

OPERATOR  METHOD  +  (IN  paramy,  param^  :  my_cla5s)  :  my_class; 

Knowledge  Base.  The  knowledge  base  body  is  a  collection  of  expressirxis  that  is  initially  in  each 
object’s  knowledge  base  when  that  object  is  allocated.  This  knowledge  base  is  defined  for  each  class  and 
may  be  empty.  The  knowledge  base  is  specified  in  a  KNOWLEDGE  MODULE  and  has  the  fcrnn: 

OBJECT  classjuune; 
expression^ 
ejqyression^ 

expression^ 

END  OBJECT; 

The  expressicms  are  DOME  Goal  Expressions,  described  in  Expressions,  p  24. 

Inheritance.  A  class  may  have  one  at  more  superclasses  from  which  it  inherits  members.  If  there 
ate  conflicting  member  names,  such  members  cannot  be  accessed  directly  by  an  instance  of  a  subclass  and 
an  error  will  be  reported  at  compile  time. 

The  fields  and  methods  of  a  superclass,  however,  may  be  overridden  with  the  OVERRIDE  directive. 
Fields  and  methods  in  the  override  section  of  the  class  declaration  supersede  those  of  the  superclasses. 

An  object  may  have  private  members  not  visible  to  methods  outside  the  class.  Private  members  are 
declared  after  the  keyword  PRIVATE. 

If  a  variable  v,  is  of  class  C,,  and  variable  Vj  is  of  class  C2  and  C,  is  a  superclass  of  C2  then  Vj  is 
assignable  to  v,.  However,  v,  is  not  assignable  to  V2  since  V2  may  have  fields  and  methods  not  jncsent  in 

Vf 

To  retrieve  a  conflicting  field  (present  in  both  C,  and  C2),  assign  V2  to  v,,  and  invoke  the  appropriate 
method.  Method  Calls  (p  25)  details  this  process. 

Within  a  method  of  a  Vj,  we  may  access  a  member  of  its  superclass  C,  by  using  the  INHERITED 
FROM  omstruct: 

INHERITED  FROM  C„/, 

where /|  is  a  field  defined  in  C,.  This  is  only  necessary  if/,  has  been  overridden  in  C,. 
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Dcciwatioos 


IMPORT  is  a  strongly  typed  language,  and  variables,  constants,  classes,  and  methods  must  be 
declared  before  being  used.  Class  and  method  declarations  are  made  in  the  DEFINITION  modules,  while 
variable  declarations  can  rally  be  found  in  the  IMPLEMENTATION  modules.  Constants  may  be  declared 
in  both  kinds  of  modules.  Class  and  method  declarations  have  already  been  described  in  Types,  p  1 1. 

Occasiraially,  recursive  or  interleaved  class  structures  may  be  required,  and  a  forward  declaration 
may  be  necessary.  In  this  case,  the  keyword  FORWARD  is  us^  to  mark  the  class. 

TYPE  my_obj  =  OBJECT;  FORWARD; 

TYPE  not_my_obj  =  OBJECT; 

field.one  :  my_obj 
END  OBJECT; 

Qasses  implemented  in  other  languages  are  declared  as  shown  above  in  the  DEFINITION  module, 
but  with  the  ^Iditional  EXTERN  statement  added.  The  default  foreign  language  is  C-H-.  The 
INTERFACE  module  facility  provides  for  renaming  of  classes,  Helds,  and  methods  as  might  be  necessary 
to  match  up  with  existing  code.  Additiraially,  they  may  be  declared  STATIC  as  IMPORT  does  not 
support  the  concept  of  static  class  members  and  functions  as  does  C-H-. 

TYPE  extemal.obj  =  OBJECT;  EXTERNAL; 
field  and  method  list 
END  OBJECT; 


Constants 

Constants  may  be  defined  in  DEFINITION  modules  and  at  any  place  variable  definitions  are  legal. 
These  are  at  the  start  of  new  scopes:  at  the  beginning  of  a  method  or  BLOCK  statement.  Constant 
declarations  have  the  form: 

CONST  id,  =  ejq>ression^-, 
idi  =  expression^. 

All  identifiers  used  in  expressions  defining  constants  must  also  be  constants  that  have  already  been 
defined. 

Variables 

Variables  may  be  declared  at  the  start  of  methods  and  BLOCK  statements.  IMPORT  is  a  lexically 
scoped  language. 

Variable  definitions  take  the  form: 

VAR  id,  :  typei, 

idi,  id, :  typCii 
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Method  Bodies 


Method  bodies  are  the  only  pl'-^s  where  imperative  or  declarative  code  can  be  found.  Excepting 
the  QUERY  method,  method  bodies  have  the  form: 

method j>rototype 

local  variable  and  constant  declarations 
BEGIN 

statement Jist 
END  METHOD. 

QUERY  methods  do  not  have  associated  bodies  in  the  IMPLEMENTATION  module.  Instead,  they 
are  entry  points  into  the  knowledge  base  for  the  class.  When  a  QUERY  method  is  invoked,  it  is  translated 
into  a  new  expression  to  be  resolved  by  the  Theorem  Proven 


Statements 

Statements  within  a  method  or  BLOCK  are  executed  sequentially.  Statements  are  terminated  with 
a  semicolon. 

Assignment 

There  are  5  forms  of  the  assignment  statement,  corresponding  to  each  of  the  four  basic  arithmetic 
operators  and  a  simple  assignment; 

x:=  3;  assigns  3  to  location  x. 

x+=  3;  increments  x  by  3. 

x-=  3;  decrements  x  by  3. 

x/=  2;  divides  x  by  2. 

x*=  3  +  5;  multiplies  x  by  8. 

The  types  of  the  location  (the  variable  on  die  left  of  the  assignment  statement)  must  match  die  type 
of  value  generated  by  the  expression  (on  the  right).  These  operators  may  be  overloaded  with  the 
OPERATOR  method  of  a  class. 

Method  Invocations 

Method  invocations  are  of  the  forms: 

method_type  objectjiame  TO  method_name(argument_list); 
method jype  objectjume  ABOUT  method jtame(argument_listy. 

The  object  rutme  is  a  variable  that  points  to  an  object.  The  keywords  TO  (used  for  ASK  and  TELL 
methods),  and  ABOUT  (used  for  QUERY  methods)  are  noise  words  and  are  optimal.  ASK,  TELL,  and 
QUERY  methods  are  invoked  in  this  way.  OPERATOR  methods  are  invoked  simply  by  using  an 
arithmetic  operatm  in  the  normal  inftx  notatim. 
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Examples: 


ASK  missile.l  TO  fire_at(target_9); 

TELL  tank.conunander  TO  attack(hi]L291); 

QUERY  foreman  ABOUT  fits_in_schedulc(project); 

new_marble_set:=  old_marble_set  +  winnings; 

Here,  the  assignment  operator  is  also  overloaded. 

There  are  (nedeflned  methods  for  each  field  of  an  instance.  If  /  is  a  field  of  instance  v,  then: 

ASK  V/. 

returns  the  value  of  /. 

If  V  is  of  type  Cj  which  inherits  from  C|,  then  we  can  invoke  methods  of  C,  by  using  the 
INHERITED  FROM  ccmstruct: 

INHERITED  FROM  C,  ASK  v  method_name(argumerti5y, 

BLOCK  Statements 

BLOCK  statements  are  a  way  of  creating  a  new,  local  scope  within  a  method.  A  BLOCK  statement 
has  the  following  form: 

BLOCK 

local  constant  and  variable  declarations 
BEGIN 

statement  list 
END  BLOCK; 

Variables  declared  within  a  BLOCK  statement  are  cmly  aj^licable  within  it,  and  within  its  subblocks. 
IF  Statements 

An  IF  statement  has  the  form: 

IF  expression^ 
statementjist 
ELSIF  ejqfression2 
statementjist 
ELSIF  expression^ 
statementjist 

ELSE 

statementjist 
END  IF; 
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The  ELSIF  and  ELSE  clauses  are  optional  and  may  be  <xnitted.  The  exfHessicms  must  be  of  type 
BOOLEAN.  The  expressions  will  be  evaluated  in  order  until  one  of  them  evaluates  to  be  TRUE.  Then 
tlM  statements  in  the  correspcHiding  statement  jist  will  be  executed. 

If  no  expression  evaluates  to  TRUE,  the  ELSE  clause  will  take  effect.  If  tteie  is  no  ELSE  clause, 
the  IF  statement  will  have  no  effect  except  for  side  effects  of  the  boolean  expressitms. 

CASE  Statement 

CASE  statements  are  a  more  efficient  way  of  comparing  an  expression  widi  a  set  Qf  constants,  when 
there  is  mote  than  one  execution  path.  The  constant  can  be  a  predefined  CONST  of  the  same  type  as  the 
expression,  or  more  usually  members  of  an  enumeration  type. 

A  CASE  statement  has  the  form: 

CASE  expression 
WHEN  const^: 

statementjist 
WHEN  constji 
statementjist 

OTHERWISE 
statementjist 
END  CASE; 

The  OTHERWISE  clause  is  optional. 

Loop  Control  Statements 

There  are  four  ways  to  write  loops  in  IMPORT,  hi  each  of  these  forms,  the  loop  terminates  if  an 
EXIT  statement  is  reached. 

LOOP 

LOOP 

statementjist 
END  LOOP; 

This  loop  must  contain  an  EXIT  statement  in  order  to  terminate. 

WHILE 

WHILE  expression 
statementjist 
END  WHILE; 

The  expression  must  evaluate  to  a  BOOLEAN  type.  If  ejq>ression  evaluates  to  TRUE,  the 
statementjist  will  be  executed  once,  before  expression  is  evaluated  again. 
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REPEAT 


REPEAT 

statementjist 
UNTIL  expression; 

The  ejq>ression  is  of  type  BOOLEAN,  statementjist  will  be  executed  once,  then  if  expression  evaluates 
to  TRUE,  die  loop  will  terminate. 

FOR 


FOR  i<i:=  first  TO  last  BY  step 
statementjist 
END  FOR; 

id  is  a  variable  of  an  ordinal  type,  first,  last,  and  step  are  expiessimis  of  the  same  ordinal  type  as 
id.  At  the  first  iteration  of  the  loop,  id  is  set  to  first,  and  ^reafter  it  is  incremoited  by  step.  The  loop 
terminates  when  the  value  of  id  is  greater  or  equal  to  last. 

TIm  keyword  TO  may  be  replaced  by  DOWNTO,  in  which  case,  id  is  decremented  by  step,  and  the 
loop  terminates  when  the  value  of  id  is  less  than  or  equal  to  last.  At  the  termination  of  the  loop,  id  holds 
the  last  value  used  in  checking  the  terminatioa  condidcm. 

RETURN  Statement 

RETURN  eqfression; 

The  RETURN  statement  is  used  to  restore  control  to  an  invoking  method.  The  type  of  expression 
must  match  the  return  type  of  the  method  in  which  the  RETURN  statement  is  found. 

TERMINATE  Statement 

TERMINATE; 

The  terminate  statement  is  used  to  stop  the  natural  sequence  of  execution  within  a  TF1.L  method. 
It  is  recursive;  the  termination  of  die  current  mediod  also  terminates  die  method  that  inv(dud  it 

WATT  Statement 

WATT  statements  are  used  in  ASK  and  TELL  mediods  to  pass  simulation  time.  They  may  have  an 
IN  l  laKRUPT  clause  whkh  will  be  executed  if  die  mediod  is  interrupted  with  the  INTERRUPT  call 
inqxirted  from  the  run-time  simulation  library.  M<ne  information  on  Interrupt  can  be  found  in  Simulation 
Support,  p  32. 

WATT  DURATION  expression 
statementjist 
ON  INTERRUPT 
statementjist 
END  WATT; 
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Ttere  are  three  forms  of  the  WATT  statement.  In  the  first,  expression  is  of  type  INTEGER  and 
gives  the  amount  of  time  to  be  passed  in  the  simulaticm. 

WATT  FOR  object jume  TO  methodjiamsiarguments) 
statement  list 

ON  INTERRUPT 
statement Jist 

END  WATT; 

In  the  second,  the  time  piassed  is  specified  within  the  niethod  that  is  invoked,  and  the  statement  list 
is  executed  after  the  method  methodjutme  is  invoked. 

WATT  FOR  TRIGGER  trigger _obJ 
statement  Jist 

ON  INTERRUPT 
statement  Jist 

END  WATT; 

In  the  third,  the  method  will  wait  for  the  specified  Trigger  object  to  fire.  Trigger  objects  fire  when 
their  Fire  method  is  invoked.  Simulation  Support,  p  32  provides  more  information  mj  the  Trigger  object. 

INTERRUPT  Statement 

There  are  two  built-in  procedures  supplied  for  stopping  TELL  methods  that  are  currently  executing 
within  an  instance  of  an  object.  They  are  the  INTERRUPT  and  INTERRUPTALL: 

INTERRUPT  (instance,  methodjutme) 

Interrupts  the  first  TELL  method  of  instance  whose  name  is  stored  as  string. 

INTERRUPTALL  (instance) 

Interrupts  all  TELL  methods  of  instaiKe. 

INTERRUPTALL  (instance,  methodjutme) 

Interrupts  all  TELL  methods  of  instance  with  the  given  string  literal  name. 

TRANSACTION  and  ABORT  Statements 

The  ccmcept  of  a  transaction  is  basic  to  shared  database  systems.  Transactions  are  necessary  to 
permit  multi-user  concurrent  access  to  shared  data  in  a  database.  For  applications  to  be  able  to  read  and 
update  the  same  data  consistently,  protocols  have  been  developed  to  overcome  problems  such  as  deadlock 
that  arbitrate  access  to  shared  data,  A  transaction  is  a  sequence  of  program  statements  that  has  exclusive 
control  over  some  shared  data.  Once  an  application  has  achieved  control  of  a  portion  of  a  database,  other 
applications  must  wait  for  it  to  finish  before  they  have  access  to  that  data.  Thus  transactions  permit  a 
group  of  program  actions  on  data  to  occur  without  interruption.  This  is  necessary  to  guarantee  integrity 
of  the  database  system.  Note  that  transaction  boundaries  widiin  concurrent  database  {q>plications  must  be 
planned  wisely.  The  goal  is  to  permit  other  q>plications  access  to  data  also.  The  amount  of  data  locked 
within  a  transaction  is  a  prime  consideration  in  multi-user  database  applications;  such  data  must  be 
structured  appropriately. 

A  major  design  requirement  for  IMPORT  is  to  provide  multi-user  concurrent  access  to  shared 
databases.  Therefore  it  is  necessary  to  provide  some  form  of  transaction  management  flexibility  within 
the  language.  In  IMPORT,  this  is  accomplished  with  the  TRANSACTION  statement.  The  TRANSAC¬ 
TION  and  ABORT  statements  are  used  when  interacting  with  persistent  storage.  Any  nontransient  NEW 
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statement,  that  is,  one  that  allocates  into  secondary  storage,  must  be  enclosed  by  a  TRANSACTION 
statement.  This  is  true  for  any  statement  that  modifles  the  state  of  a  Database.  The  actions  on  a  Database 
within  a  transaction  are  atomic,  and  either  all  actions  on  a  Database  within  a  transaction  are  completed, 
or  none  are  completed. 

A  transaction  may  be  aborted  by  the  object-oriented  database  system,  or  it  may  be  aborted  by  the 
programmer  with  the  ABORT  statement.  TRANSACTION  statements  may  have  an  ABORT  clause,  which 
is  executed  when  the  transaction  is  aborted.  A  TRANSACTION  statement  has  the  form: 

TRANSACTION 
statement Jist 
ON  ABORT 
statement  Jist 
END  TRANSACTION; 

Abort  statements  have  two  forms: 

ABORT; 

ABORT  ALL; 

The  first  form  aborts  the  deepest  enclosing  TRANSACTION,  and  ABORT  ALL  aborts  all  enclosing 
transactions. 

IMPORT  Statements 

IMPORT  statements  are  used  to  share  classes  between  modules,  and  have  the  form: 

FROM  module  I  IMPORT  id,,  id^, 

FROM  module2  IMPORT  ALL  id^, 

FROM  module^  IMPORT  id^  AS  idj, 

FROM  module^  IMPORT  id^iidj  AS  id^); 

The  first  statement  imports  id,  and  I'dj.  The  second  statement  imports  id^,  which  is  an  enumerated 
type,  and  all  its  members.  The  third  statement  imports  id^  in  module^  and  renames  it  to  idj  in  this  module. 
The  fourth  statement  imports  id^,  an  enumerated  type,  and  only  one  member  of  the  enumeration  id,,  and 
renames  it  to  id^. 


Dynamic  Memory  Management 

NEW 


The  NEW  built-in  procedure  allocates  memory  for  the  creation  of  object  instances.  Suppose  id,  is 
of  type  class,.  Then  NEW  (id,)  creates  an  instance  of  class,  in  transient  memory.  Additionally, 
parameters  to  the  CONSTRUCTOR  method  of  an  object  may  be  specified: 

NEW  {id,(arg, . arg„) 


To  allocate  an  object  instance  into  persistent  store, 
NEW  (id,,  database Jnjise) 
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creates  a  persistent  instance  of  c/osf ,  in  the  object-oriented  database  database _Jn_use.  database_in_jise 
is  a  variable  of  type  Database.  Objects  can  also  be  allocated  in  Segments  and  Configurations.  The  class 
libraries  used  to  support  persistence  are  covered  briefly  in  Database  Class  Library,  p  32  and  fully 
described  in  Af^ndix  B. 


DISPOSE 

The  DISPOSE  built-in  procedure  returns  transient  objects  to  the  heap  and  removes  a  persistent  object 
from  the  database: 

DISPOSEfmy.oty); 


Expressions 

An  expression  is  a  computation  that  produces  a  value.  An  expression  is  either  an  q>erand  or  an 
operator  applied  to  operands.  An  expression  is  evaluated  by  recursively  evaliiating  its  operands,  then 
applying  the  operator  to  it.  The  order  of  argument  evaluation  is  undefined;  in  particular,  there  are  no 
“short-circuit”  BOOLEAN  expressions. 

Operators  and  Precedence 

Method  invocations,  built-in  function  calls  and  array  indexing  always  have  the  highest  priority,  after 
which  the  priority  and  associativity  are  listed  in  decreasing  priority  (Table  1).  All  the  operators  are  infix 
operators. 

Integer  Literals 

INTEGER  literals  may  be  represented  in  decimal  or  hexadecimal  (when  appended  by  the  letter  H). 
Example: 

A091H 


Table  1 

Operator  Associativity  by  Decreasing  Priority 


Operator 

unary  — 
•/DIV  MOD 


=  <><>>=!<= 


NOT 

AND 

OR 


Associativity 

ri^t 

leA 

left 

non-associative 

ri^t 

left 

left 
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Character  Literals 


Character  literals  are  rqjresented  by  a  printable  character  in  single  quotes  or  a  decimal  niunber  from 
0  to  2SS  followed  by  the  letter  C. 

Example: 

54C 

String  Literals 

String  literals  consist  of  a  sequence  of  printable  characters  on  one  line  within  double  quotes. 
Example: 

"This  is  a  string." 

Floating  Point  Literals 

Floating  point  REAL  literals  are  represented  in  decimal  form,  or  in  scientific  notation. 

Examples: 

1.0 

0.31 

1.3E+20 

All  literals  must  have  an  integer  portion  and  a  fiaction  portion.  The  numbers:  1.  and  .2,  are  not 
legal  floating  point  literals. 

Lists 


Lists  are  denoted  by  expressions  separated  by  conunas  within  square  brackets. 

Example: 

["string",  34,  y] 

The  example  shows  a  list  of  three  elements,  consisting  of  a  string,  an  integer,  and  the  value  of 
variable  y. 

Designators 

A  designator  is  an  expression  that  denotes  the  location  where  a  value  is  held.  Variables  used  in 
expressions  are  designators.  a[i],  where  a  is  an  array,  and  i  is  an  ordinal,  denotes  the  ith  element  in  array 
a,  and  is  also  a  designator.  These  are  the  only  two  kinds  of  designators. 

Method  Calls 

Invocations  of  methods  that  return  a  value  are  also  expressions.  The  type  of  the  expression  is  the 
type  of  the  return  value  of  the  method. 
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Arithmetic  Operations 

The  basic  arithmetic  operations  are  built  into  the  language  and  are  defined  for  REALs  and 
INTEGERS.  In  addition,  DIV,  which  returns  the  quotient  of  an  INTEGER  divisicm,  and  MOD,  which 
returns  the  renuunder  of  an  INTEGER  division,  are  also  defmed.  All  arithmetic  operators  are  infix 
operators.  The  type  of  the  expression  returned  by  the  arithmetic  operation  is  the  type  of  its  operands. 

Relations 

The  relations  less  than  (<),  greater  than  (>),  equal  to  (=),  less  than  or  equal  to  (<=),  greater  than  or 
equal  to  (>=)  and  not  equal  to  (o)  are  built  into  the  language  for  ordinals  and  floating  point  numbers. 
The  type  of  a  relation  is  always  BCX)LEAN. 

Boolean  Operations 

The  operations  logical-and  (AND),  logical-or  (OR),  and  logical-not  (NOT)  are  defined  for 
BOOLEANs.  The  expression  formed  with  these  operators  are  also  of  type  BOOLEAN. 

NULL 

The  keyword  NULL  designates  a  null  value.  This  can  be  an  object,  or  a  STRING. 
UNINSTANTIATED 

The  keyword  UNINSTANTIATED,  when  assigned  to  a  variable,  denotes  a  variable  that  has  no 
value.  This  is  used  in  conjunction  with  QUERY  methods  to  determine  the  result  of  computation.  For 
more  informatimi,  see  The  Theorem  Prover  (p  26). 

The  value  of  UNINSTANTIATED  is  implementation  dependent,  but  is  usually  the  largest  negative 
INTEGER  for  integer  and  enumerated  types,  0  for  CHARs,  NaN  (not  a  number)  for  floating  points,  and 
a  pointer  to  a  unique  location,  usually  NULL,  for  other  types  of  variables. 

Relationship  to  DOME 

IMPORT  was  designed  to  support  a  declarative  progranuning  facility.  This  c^bility  is  supplied 
through  integration  with  DOME,  wMch  was  develop^  in  conjimction  with  IMPORT  (Whitehurst  and 
Pietizak  1993). 

The  DOME  Theorem  Prover 

The  DOME  theorem  prover  is  based  on  Prolog,  widi  a  similar  Horn  Clause  unification  model.  Each 
expression  represents  a  Horn  Qause,  and  is  asserts!  into  the  knowledge  base  of  the  object  that  ccHitains 
it  Clauses  can  be  added  to  a  knowledge  base  through  the  KNOWLEDGE  section  of  an  object  or  through 
QUERY  method  deflnitimis. 

Within  a  proof,  all  clauses  are  considered  equivalent.  The  difference  between  the  two  ways  of 
adding  clauses  to  an  object  involve  how  a  proof  is  invoked:  All  clauses  that  appear  in  the  KNOWLEDGE 
sectirai  are  for  the  internal  use  of  the  theorem  prover.  QUERY  methods,  however,  can  be  called  from 
other  IMPORT  methods,  in  a  manner  similar  to  ASK  and  TELL  method  invocations. 
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The  <»der  of  clauses  with  a  head  of  the  same  name  is  signiilcant;  duiiiig  a  proof,  die  idi  clause 
encc  >red  will  be  chosen  before  the  (di  +  1. 

Parameters  within  a  QUERY  invocation  are  split  logically  into  two  types:  ccmstant  (or  instantiated), 
and  uninstantiated.  The  cmistant  parameters  can  be  any  constant  or  variable  declared  within  IMPORT, 
except  those  variables  specifically  declared  as  uninstandated.  C^mstant  parameters  are  used  directly  by 
the  theorem  prover,  and  are  not  nradified.  Uninstandated  variables  are  modified  depouling  cm  the  success 
of  the  {HOof. 

When  a  QUERY  method  is  invoked,  the  theorem  prover  wUl  attempt  to  uiufy  the  given  parameters 
with  the  clauses  available  in  that  object’s  knowledge  base.  Due  to  inheritance,  it  may  also  search  odier 
knowledge  bases  for  a  soludon.  When  it  has  finished  attempting  to  prove  the  query,  the  dieorem  prover 
will  return  true  or  false  depending  on  its  success.  If  it  returns  true,  it  will  also  assign  the  substituted 
values  used  to  solve  the  proof  into  the  corresptmding  uninstandated  variables  passed  on  (Figure  2). 

Note:  Only  the  flrst  solutitm  found  by  the  theorem  prover  will  be  returned;  other  potential  solutitxis 
are  ignored. 

DOME  Goal  Expressions 

The  DOME  “goal”  expression  is  encoded  into  an  asserticm  or  a  query  to  be  executed  by  the  DOME 
proof  procedure.  These  expressions  can  only  be  found  in  the  KNOWLEIXjE  module.  The  syntax  of  a 
DOME  goal  expression  is  always  of  the  form: 

(2, ....  (^ 

where  /  is  the  name  of  die  goal,  and  the  tfi  are  the  arguments  of  the  goal.  Each  tfi  is  a  DOME  term. 
An  example  of  such  an  expressitm: 
age  (John,  23) 

where  “John”  is  a  symbol,  and  “23”  is  an  integer  constant  Bodi  are  considered  as  terms  in  DOME 
parlance. 

DOME  Terms.  There  are  three  kinds  of  DOME  terms:  constants,  variables,  and  lists.  A  constant 
DOME  term  can  be  an  integer,  string,  symbol,  etc.,  defined  just  as  normal  constants  are  within  IMPORT. 
However,  variables  within  IMB  >RT  are  treated  as  eitiier  constant  DOME  terms  or  variable  DOME  terms, 
depending  on  their  value:  An  msMitiated  variable  is  considered  to  be  constant  by  the  theorem  prover,  but, 
an  uninstantiated  variable  is  considered  to  be  a  variable  DOME  term  when  given  in  a  query,  and  thus  the 
theorem  prover  is  allowed  to  assign  some  value  to  it.  A  list  is  a  variable  of  type  LIST. 


Success 

Gmstant 

Uninstantiated 

FALSE 

No  effect 

No  efiect 

TRUE 

No  effect 

Instantiated,  if  necessary 

Figure  2.  Effect  of  Return  of  QUERY  Invocation  On  Given  Parameters. 
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Built’in  Procedures  and  Functions 


IMPORT  inherits  the  built-in  procedures  and  functions  of  ModSim  with  a  few  additions,  all  of  which 
are  reproduced  here  for  easy  reference.  The  built-in  procedures  are  shown  below  using  a  syntax  close  to 
that  of  methods  in  terms  of  their  parameters.  In  the  following  descriptions,  square  brackets,  [],  represent 
of^onal  arguments. 

Built-in  Procedures 

ABORT  [ALL] 

Aborts  the  current  transaction.  ABORT  ALL  aborts  the  current  and  all  enclosing  transaction. 

DECflNOUT  arg  :  AnyOrdinal  [;  n  :  INTEGER]) 

Decrements  any  ordinal  (enumeration,  integer,  or  character)  typed  variable.  Decrements  by  one 
unless  optional  parameter  specifies  differently. 

DISPOSE(IN  arg  :  AnyObject) 

Free  memory  associated  with  a  variable  of  type  OBJECT:  transient  or  persistent. 

HALT 

Terminates  execution  of  a  program.  All  transactions  are  aborted. 

INC(INOUT  arg  :  AnyOrdinal  (;  n  :  INTEGER]) 

Increments  any  ordinal  (enumeration,  integer,  or  character)  typed  variable.  Increments  by  one  unless 
optional  parameter  specifies  differently. 

INPUT(OUT  arg,  :  SomeType  liargi :  SomeType  . .  .  ]) 

Reads  from  standard  input  and  places  values  into  each  of  the  parameters.  Input  values  may  be 
separated  by  spaces,  tabs,  or  newlines.  SomeType  must  be  CHAR,  INTEGER,  REAL,  or  STRING. 

INSERT(INOUT  str,  :  STRING;  IN  pos  :  INTEGER;  IN  str,  :  STRING) 

Inserts  str,  at  pos  in  stTj.  Numbering  of  positions  in  STRINGS  begins  at  position  zero  (0). 

NEW(OUT  obj  :  AnyObject  [;  IN  Database  |  Segment  |  Configuration  ]) 

Allocates  storage  to  a  variable,  obj,  in  either  transient  or  persistent  memory.  Persistent  allocation 
requires  speciflcadon  of  a  location  in  terms  of  an  object  of  type  Database,  Segment,  or  Corfigura- 
tion. 

OlJTPUT(IN  argi  :  SomeType  [;  argj :  SomeType  . . .  ]) 

Places  the  contents  of  the  variables  given  as  parameters  on  the  standard  output  device.  SomeType 
must  be  CHAR,  INTEGER,  REAL,  or  STRING. 
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REPLACE(INOUT  itr,  :  STRING;  IN  pos„  pos^  :  INTEGER;  IN  str^ :  STRING) 
Replaces  tfiat  part  of  str^  beginning  at  po5,  and  ending  at  pos2  with  j/Tj. 


STRTOCHAR(IN  str  :  STRING;  OUT  ArrayOfChar  :  ARRAY  OF  CHAR) 

Converts  str  to  an  :  ARRAY  OF  CHAR)  stored  in  the  variable  ArrayOfChar. 

INTERRUPT(IN  obj  :  AnyObject,  IN  method  :  STRING) 

Interrupts  most  imminent  method  of  AnyObject  returning  control  to  the  point  of  invocation, 
activating  the  ON  INTERRUPT  clause,  if  any. 

INTERRUPTALL(IN  obj  :  AnyObject  [;IN  method :  STRING) 

Interrupts  the  ALL  methods  named  method  of  AnyObject.  If  no  mediod  is  specified,  interrupts  all 
pending  TELL  methods. 

Built-in  Functions 

ABS(IN  arg  :  INTEGER  |  REAL) :  INTEGER  |  REAL 
Returns  the  absolute  value  of  the  argument 
APPENIHIN  /wr„  list2,  LIST) :  LIST 

Creates  a  new  LIST  from  lirt,  and  list2  and  returns  it. 

CAPON  ch  :  CHAR) ;  CHAR 

Returns  the  coital  (uppercase)  character  corresponding  to  the  argument 

CHARTOSTR(IN  ArrayOfChar  :  ARRAY  OF  CHAR) :  STRING 

Returns  a  value  of  type  STRING  based  oi  ctmversion  of  the  input  ARRAY  OF  CHAR  type 
argument 

CHRON  n  :  INTEGER) :  CHAR 

Returns  the  CHAR  corresponding  to  the  INTEGER  argument  The  range  is  0-255. 

FLOATON  n  :  INTEGER) :  REAL 

Returns  the  REAL  value  of  tlw  INTEGER  argument 
HEADON  list :  UST) :  LIST 

Returns  die  elemoit  at  the  head  of  the  LIST  list. 
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INTTOSTR(IN  n  :  INTEGER)  :  STRING 

Returns  a  STRING  value  representing  the  INTEGER  argument 
LENGTH(IN  list :  UST)  :  INTEGER 
Returns  the  length  of  the  list. 

LOWER(IN  str  :  STRING)  :  STRING 

Returns  a  value  of  type  STRING  ccmesponding  to  the  argument  in  all  lowercase. 
MAXiScalarType)  :  ScalarType 

Returns  the  maximum  value  of  the  given  type  that  is  representable  by  the  computer. 
MAXOF(IN  argi  :  ScalarType  [;IN  arg,  :  ScalarType  J) :  ScalarType 

Returns  the  maximum  value  of  all  the  arguments.  The  arguments  must  be  of  the  same  type 
MINiScalarType) :  ScalarType 

Returns  the  mimimum  value  of  the  given  type  ttiat  is  represoitable  by  the  computer. 
MINOF(IN  arg,  :  ScalarType  [;IN  org,  :  ScalarType  1) :  ScalarType 

Returns  the  minimum  value  of  all  the  arguments.  The  arguments  must  be  of  the  same  type. 
NTH(IN  int :  INTEGER;  IN  list) :  LIST 
Returns  the  /tth  element  of  the  list. 

ODD(IN  n  :  INTEGER) :  BOOLEAN 

Returns  TRUE  if  the  argment  is  odd,  otherwise  FALSE. 

ORD(IN  arg  :  OrdinalType) :  INTEGER 

Returns  the  ordinal  value  of  the  argument 
PERS1STENT(IN  obj  :  ObjectType) :  BOOLEAN 

Returns  TRUE  if  the  argument  has  been  allocated  to  persistent  store,  otherwise  FALSE. 
POSmONON  str^,  str2 :  STRING) :  INTEGER 

Returns  die  position  of  str^  in  stTj.  Position  is  numbered  begining  from  zero  (0). 
REALTOSTRON  arg  :  REAL):  STRING 

Returns  a  STRING  value  represoiting  the  REAL  argument 
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ROUNEKIN  arg  :  REAL)  :  REAL 

Returns  the  argument  rounded  to  the  nearest  integer. 

SCHAR(IN  str  :  STRING;  IN  pos  :  INTEGER)  :  CHAR 

Returns  the  character  at  position  pos  counting  from  zero  (0)  as  the  first  position. 

SIMTIMEO  :  INTEGER 

Returns  the  current  simulation  time. 

STRCAT(IN  srr,.  str^  [,  str,  ])  :  STRING 

Returns  the  STRING  consisting  of  the  concatenation  of  the  arguments. 

STRLENON  str  :  STRING) :  INTEGER 

Returns  the  length  of  the  STRING  s/r  as  an  INTEGER. 

STRPUTflN  arg,  :  SomeType  [;  argj :  SomeType  ...]):  STRING 

Returns  the  STRING  consisting  of  die  concatenation  of  the  arguments.  The  arguments  are  converted 
to  their  STRING  representadon.  SomeType  . . .  may  be  CHAR,  INTEGER,  REAL,  ARRAY  OF 
CHAR,  or  STRING. 

STRTOINTdN  str  :  STRING) :  INTEGER 

Returns  the  INTEGER  representation  of  the  STRING  argument. 

STRTOREALON  str  :  STRING) :  REAL 

Returns  die  REAL  representation  of  the  STRING  argument. 

SUBSTRflN  poSy,  posj :  INTEGER;  IN  str  :  STRING) :  STRING 

Returns  the  part  of  the  str  beginning  at  poSy  and  ending  at  posi-  Positions  are  numbered  begiiming 
at  zero  (0). 

TAILON  list ;  UST) :  LIST 

Returns  the  LIST  starting  at  the  second  element 
TRUNCON  arg  :  REAL) :  INTEGER 

Returns  the  INTEGER  valued  part  of  the  REAL  parameter. 

UPPERON  str  :  STRING) :  STRING 

Returns  a  value  of  type  STRING  corresponding  to  the  argument  in  all  uppercase. 
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''AL(IN  OrdimlTypeName-,  IN  OrdNum  :  INTEGER)  :  OrdinalType 


Returns  the  value  of  the  ordinal  type  name,  e.g.,  CHAR,  at  the  given  ordinal  position. 


Standard  Library  Modules 

The  IMPORT  language  depends  on  Standard  Libraries  to  achieve  certain  capabilities.  At  present, 
these  consist  of  modules  for  simulation  support  and  persistence.  These  are  needed  as  a  minimum,  and 
additional  modules  are  planned  to  provide  a  basis  for  general  applications  development. 

Simulation  Support 

Simulation  time  is  kept  as  an  INTEGER  with  no  associated  units. 

SIMTIME  0 

Returns  an  INTEGER  that  is  the  current  simulated  time. 

Simulation  granularity  is  user-defined.  Each  TELL  method  creates  a  new  task  and  any  TELL 
method  may  create  more  than  one  active  task  at  a  time. 

The  main  feature  of  the  simulation  environment  beyond  the  WATT  and  TELL  constructs,  is  the 
Trigger  class,  used  for  synchronization.  The  nmtime  module  is  included  automatically  with  each 
module  and  contains  the  definition  of  the  Trigger. 

DEFINITION  MODULE  RT; 

Trigger  =  OBJECT; 

ASK  METHOD  Fire  Q; 

ASK  METHOD  InteiruptTrigger  Q; 

END  OBJECT; 

END  MODULE. 

Invoking  the  Fire  0  method  of  a  Trigger  releases  all  tasks  that  are  waiting  on  the  Trigger.  Invoking 
InterruptTrigger  Q  causes  all  tasks  waiting  on  the  Trigger  to  execute  the  ON  INTERRUPT  portion 
of  the  WATT  FOR  TRIGGER  statement  instead. 

Database  Class  Library 

IMPORT  provides  a  database  class  library  supporting  persistent  object  storage.  Objects  are  allocated 
into  persistent  store  using  the  NEW  procedure  (described  in  Dynamic  Memory  Management,  p  23).  All 
interaction  with  a  database  must  be  enclosed  within  a  TRANSACTION  statement,  p  22.  Table  2  lists  the 
database  classes.  The  full  class  definitions  are  given  in  Appendix  B. 
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Tabk2 


Database  Classes 


Class 

Descilpfloa 

Database 

Contains  information  on  where  other  objects  are  stored 

Directoiy 

Allows  hierarchical  storage  of  roots  in  the  Database 

List 

An  ordered  collection  of  objects 

ListCursor 

Cursor  for  a  List 

Tree 

Generalized  tree  of  objects 

TreeCursor 

Cursor  for  a  Tree 

Configuration 

Configuration  for  versioning 

Workspace 

Workspace,  where  configurations  of  objects  are  checked  into,  and  modified 
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3  IMPLEMENTATION 


The  object-oriented  approach  to  software  design  and  development  is  most  generally  characterized 
as  modeling.  The  resulting  software  systems  can  be  drought  of  as  simulations.  IMPORT  was  motivated 
by  the  requirements  for  complex  system  modeling  and  simulation.  To  respcMid  to  these  requirements,  it 
was  natural  to  take  this  same  approach  to  implementaticm.  In  this  regard,  the  implementation  of  IMPORT 
mcMe  closely  resembles  a  state-of-the-art  CAD  system  than  a  programming  language.  Dart  (1990)  gives 
an  insightful  analysis  of  the  benefits  achievable  in  software  development  envinxunents  by  adopting  CAD 
system  approaches. 


Introduction 

The  implementation  strategy  of  IMPORT  supports  the  goals  of  software  engineering  in  general  and 
anticipates  specific  requirements  fo>'  its  intended  use  within  a  software  develc^ment  environment.  From 
the  software  engineering  perspective,  IMPORT  is  implemented  as  an  object-oriented  framework  modeUng 
an  Intermediate  Representation  of  the  language.  The  modeling  approach  supports  understandability  and 
maintainability  as  it  reflects  a  close  correlation  between  conventional  compiler  constructs  aral  software 
classes.  The  tools  chosen  for  implementation  are  reliable,  efficient,  and  portable.  The  framework 
approach  is  the  best  current  thinking  in  software  engineering  for  reusability  through  design  iteration 
(Johnson  and  Foote  1988).  The  verification  of  a  language  is  more  constrained  than  many  general 
applications,  and  test  suites  have  been  developed  that  exercise  all  specifications  of  the  implementation. 
Validation  of  the  requirements  on  which  the  design  rests  requires  the  use  of  the  language  in  the 
development  of  applications  of  the  type  for  which  it  was  built.  Efforts  in  this  direction  are  underway. 

Requirements  differentiating  IMPORT  from  other  languages  are  those  related  to  software 
development  environments.  Generally,  IMPORT  is  intended  to  be  used  within  a  distributed,  collaborative 
software  engineering  development  environment.  Tlte  trend  toward  the  use  of  object-raiented  database 
systems  as  the  underlying  mechanism  to  support  such  systems  seems  clear.  This  approach  permits  a 
number  of  significant  benefits  and  offers  a  more  integrated  soluticMi  to  some  Iraigstanding  problems. 
Perhaps  the  most  interesting,  from  a  research  point  of  view,  is  in  ctHifiguration  management  (Kalathil  and 
Herring  1993).  IMPORT  may  be  the  first  fully  functional  programming  language  with  an  impiementatioi 
based  on  an  object-oriented  database  with  the  aim  to  provide  consistent  and  integrated  support  within  a 
software  engineering  environment.  Longer  term  plans  include  knowledge-based  software  engineering  that 
places  further  requirements  on  representations  for  reasoning  about  software  artifacts  (Lubars  and  Havandi 
1987).  Chapter  4  develops  an  overview  of  the  motivation  for  these  and  other  related  requirements.  Brown 
(1991)  gives  a  good  summary  statement  of  requirements  for  software  artifact  object  repositories. 

This  chapter  describes  the  implementation  of  the  IMPORT  compiler,  beginning  with  a  brief  overview 
of  compilation  as  it  relates  to  the  structure  of  the  IMPORT  compiler  (Aho,  Sethi,  and  Ullman  1986). 

Compilation  is  the  process  of  transforming  programs  from  the  source  language  (high-level)  fmmat 
into  some  target  (lower-level)  format  This  process  can  be  divided  into  two  stages:  analysis  and  synthesis. 
The  analysis  frfiase  decomposes  source  input  into  elemental  components  represented  in  some  convenient 
intermediate  form.  The  synthesis  phase  assembles  the  target  format  program  based  cm  the  intermediate 
Kfmsenatitm.  Analysis  cmisists  of  three  parts;  linear,  hierarchical,  and  semantic  analysis.  Linear  analysis, 
often  called  lexical  analysis,  views  the  source  program  as  a  sequence  of  characters.  During  this  phase, 
characters  are  read  in  and  grouped  into  symbols  or  tokois  of  the  language,  i.e.,  keywords  and  identifiers. 
The  tokens  recognized  in  lexical  analysis  are  passed  on  to  the  next  step.  In  hierarchical  analysis,  often 
called  syntax  analysis  or  parsing,  the  tokens  are  further  grouped  into  collections  having  some  higher-level 
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meaning  in  the  source  language.  These  collections  usually  take  the  fonn  of  parse  trees  or  syntax  trees. 
That  is,  they  are  naturally  hierarchical  in  structure.  These  hierarchical  structures  are  processed  during 
semantic  analysis  to  ensure  program  correctness  (at  the  next  higher  level  of  abstraction)  and  insert 
information  needed  for  the  subsequent  synthesis  phase.  Synthesis  uses  the  results  of  arudysis  to  produce 
the  target  formated  ouqwt  There  are  several  approaches  depending  on  the  host  and  target  hardware  and 
software  envirorunent  It  is  common  in  the  syi^sis  phase  to  produtre  another  intermediate  (machine 
independent)  representation  and  to  optimize  it.  This  optimized  form  is  then  translated  to  the  binary  fonnat 
of  the  target  machine.  System  utilities  take  care  of  linking  aj^ropriate  libraries  and  other  needed  runtime 
support  to  produce  the  f^  executal^e.  Figure  3  gives  an  overview  of  the  components  of  die  IMPORT 
com{Hler. 

The  Lexer,  Parser,  and  Semantic  Controller  constitute  the  ennponents  of  the  analysis  phase.  The 
bottom  three.  Code  Generator,  CompUer/Linker,  and  Runtime  comprise  the  components  of  the  synthesis 
[diase.  In  traditional  compilers,  these  components  create  intermediate  representations  in  transient  memory. 
IMPORT  is  distinct  in  that  an  Object  Repository  is  used  to  store  an  extended  intermediate  representation. 
The  repository  is  shown  at  the  center  of  the  diagram  as  all  components  interact  with  it  in  performing  their 
respective  actions.  Necessary  to  all  [diases  of  the  oimpUation  process  is  the  management  of  the  Symbol 
Table  and  other  bookkeeping  functions. 

Given  this  overview  of  the  components  of  the  compiler  and  their  interaction,  the  (uesentation  is 
organized  as  follows.  Begirming  with  the  object  model  of  the  intermediate  representation,  which  forms 
the  structure  of  the  object  repository  and  provides  the  basis  for  a  discussion  of  the  analysis  portion.  The 
synthesis  part  of  the  compiler  follows,  which  includes  the  code  generator,  the  DOME  interpreter  interface, 
and  the  simulation  runtime  support  Finally,  the  role  played  by  the  Generic  Object-Oriented  Database 
(GOOD)  interface  in  implementation  of  the  compiler  and  support  for  persistem  programming  in  the 
IMPORT  language  is  described. 


Figure  3.  IMPORT  Components  and  Their  Relationships. 
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ModeliBg  IMPORT:  The  Intermediate  RepreMntation 

This  section  presents  the  intermediate  representation  designed  to  support  compilation  as  well  as  the 
application  domain  goals  of  the  IMPORT  compiler.  The  representation  is  designed  to  be  generic,  and  yet 
have  enough  correspondence  with  other  modular  object-oriented  prognunming  languages  to  facilitate 
translation  to  and  from  these  languages.  This  especially  helps  in  code  generation.  Appendix  C  includes 
the  C++  header  files  for  the  classes  described  in  this  section. 

The  simplest  internal  representation  of  a  program  is  a  parse  tree  with  an  associated  symbol  table. 
However,  additional  information  that  is  useful  during  compilation  and  in  the  development  of  software 
engineering  tools  is  also  required.  To  meet  these  goals,  a  set  of  Software  Engineering  Environment  (SEE) 
classes  that  form  the  basis  for  interaction  between  the  tool  set  were  designed.  (The  overall  structure  of 
the  environment  and  tools  are  discussed  in  Chapter  4.)  The  SEE  classes  are  used  to  represent  the 
imperative  portion  of  an  IMPORT  program.  The  declarative  portion  of  the  program  is  translated  into  a 
knowledge-base  representation.  This  takes  the  form  of  a  collection  of  expressions  identical  to  the 
implementation  of  the  first  class  data-type  LIST.  Details  of  how  this  is  used  in  the  interface  between 
IMPORT  applications  and  the  IX)ME  theorem  prover  can  be  found  in  The  DOME  Runtime  Interpreter 
Interface,  p  46. 

The  general  structure  of  a  module  (or  application)  is  decomposed  into  the  hierarchical  form  shown 
in  Figure  4.  This  form  follows  the  structure  of  the  IMPORT  language  closely.  A  module  contains 
declarations  (constants  and  types)  and  classes.  Classes  are  composed  of  declarations  (fields)  and  methods. 
Methods  contain  local  declarations  (constants,  types,  and  variables)  and  the  statements  that  make  up  the 
body.  During  compilation,  each  node  shown  in  the  tree  structure  becomes  an  instance  of  one  of  the  SEE 
classes. 


Module 


Local  Variables  and  Constants  Operator  and  Argianent  nodes 


Figure  4.  Modeling  Software  With  Objects. 
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At  this  point,  a  more  fonnal  notation  is  introduced  to  describe  the  SEE  classes.  This  notation  comes 
from  the  object-oriented  analysis  and  design  methodology  known  as  Object  Modeling  Technique  (OMT) 
(Rumbaugh  1987).  Explanations  of  the  symbology  used  in  OMT  will  be  given  as  it  is  encountered.  A 
limited  subset  of  OMT  was  taken  from  the  OMT  Object  Model.  Figure  5  shows  the  OMT  equivalent  of 
Figure  4. 

The  “part-of  ’  relationship  among  classes  is  called  aggregation.  The  diagram  shows  the  aggregation 
relationships  among  the  SEE  classes  id_Module,  id_Class,  id_Method,  Declaration,  and  ast_node.  The 
diamond  symbol  (under  id.Module)  stands  for  the  aggregation  relationship  that  exists  between  id_Module 
and  id_Class  as  exi^ained  above.  The  soild  circle  shows  this  relationship  is  “one-to-many”:  a  module 
contains  zero  or  more  classes.  A  detailed  presentation  of  structure  of  tlK  SEE  classes  and  their  supporting 
classes  is  given  below. 

Modules 

Each  application  is  composed  of  modules.  Figure  6  shows  the  attributes  for  the  class  id.Module. 
The  id_Module  attributes  include  the  module_name,  which  is  a  string,  and  a  module.type,  which  is  an 
integer.  Two  attributes  assisting  in  code  generation  are  last_touch  and  has_extemal_obj.  The  first  of  these 
stores  an  integer  value  corresponding  to  the  date  and  time  of  compilation,  and  the  last  indicates  whether 
the  module  has  externally  defined  classes.  Three  of  the  attributes  are  pointers  to  other  classes.  The  decl 
is  a  pointer  to  an  instance  of  class  Declaration  that  is  examined  in  detail  later.  The  two  remaining 
attributes  are  instances  of  idjoodbjist  (See  The  GOOD  Common  Interface,  p  S3).  The  classes  attribute 
is  a  list  or  collection  of  the  classes  declared  (or  defined)  in  the  module,  and  imported.modules  is  a  list 
of  the  modules  imported  for  type  visibility.  An  ONfT  class  diagram  shows  methods  of  the  class  as  well 
as  attributes.  In  the  case  of  id.Module,  there  is  ordy  one  constmctor  and  a  destructor.  These  methods 
are  omitted  from  this  and  future  diagrams  because  they  are  assumed  for  all  classes. 


Figure  5.  OMT  Diagram  of  SEE  Classes. 
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id_Modu]e 

module.name  :  character 
module_type :  integer 
classes  :  id_oodb_iist 
iinported_module8  :  id_oodbJist 
decl :  Declaration 
last_touch  :  integer 
has_extemal_obj  :  boolean 


Figure  6.  Class  Diagram  of  the  Id_Module  Class. 


id.Class 

se  :  symtab.entry 
super.classes  :  symtab.entryjist 
8torage_type  :  type_expression_list 
methods  :  id_o^b_list 
tell_methods :  id.oodbjist 
decl :  Declaration 
is_forward :  integer 
is.extemal :  integer 
knowledge :  id_oodb_list 


Figure  7.  Class  Diagram  of  id_Class. 


Classes 

The  id_Class  models  an  IMPORT  “Object”  It  craitains  types  and  names  of  fields,  access  rights, 
and  inheritance  information.  In  each  is  also  a  collection  of  methods  (Figure  7). 

Each  object  in  a  module  must  be  stored  in  the  symbol  table.  id_Class  ctmtains  an  attribute  for  this 
purpose:  se,  which  is  a  pointer  to  an  instance  of  sjmitab.entry  class.  The  attribute  symtab_entry_list 
contains  pointers  to  instaiKes  of  symtab_entry  for  each  class  from  which  the  instance  inherits.  This  is 
necessary  for  code  generation.  Also,  id_Class  must  store  the  mediods  of  the  class.  This  is  accoiiq>lished 
by  an  id_oodbJist  A  distinction  is  made  for  TELL  methods  as  they  require  special  handling  during  code 
generadmi.  A  pointer  to  an  instance  of  Declaration,  decl,  holds  die  declaration  of  the  fields  of  die  object 
is.forward  and  is_extemal  are  needed  both  for  parsing  and  code  generation.  The  declarative  statements 
from  the  KNOWLEDGE  module  are  stored  in  another  id_oodb_list  in  the  attribute  gknow. 

Methods 

IMPORT  methods  are  modeled  by  the  id.Method  class.  Instances  of  this  class  describe  the  various 
methods  supported  by  IMPORT,  characteristics  such  as  parameter  names  and  types,  the  type  of  any  value 
returned,  local  variables,  and  abstract  syntax  trees  that  describe  the  statements  in  each  method.  The 
id_Method  class  is  shown  below  in  Figure  8. 

Each  instance  of  id.Mediod  contains  a  symbol  table  entry,  se,  for  the  method  and  a  method  type 
indicator.  The  parameters  to  the  metluxl,  paims,  are  stored  in  an  instance  of  symtab_entryjist  and  their 
types,  parm_type,  are  stored  in  an  instance  of  type_expression_list  The  storage  type  of  the  returned  value, 
if  any,  is  found  in  storage.type  of  which  is  also  represented  as  a  type_expression_list.  A  pointer  to  an 
instance  of  Declaration,  decl,  stores  the  locally  declared  variables  of  the  method  and  aif  is  a  pointer  to 
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_ id_a«st 

se  :  symiab.entiy 
method.type  :  iiUego’ 
pann.type  :  type_exineMion_lut 
storage.type  :  type_expressionJi>t 
pamu  :  symtab.entiy  Jist 
of.clau  :  symub.oitzy 
decl :  Declaration 
asf :  ast_iiode 
is_public  :  boolean 


Figure  8.  Class  Diagram  of  id_Metliod. 


Operator  and 


Figure  9.  Node  in  the  Abstract  Syntax  Tree. 

the  ast.node,  \«1iich  stores  the  body  of  the  metlKxL  The  is_private  boolean  attribute  indicates  if  the 
method  is  declared  PRIVATE  in  the  definition  module. 

Abstract  Syntax  Nodes  and  Tree 

The  abstract  syntax  tree  iast)  is  a  commonly  used  stnicture  for  storing  information  obtained  about 
a  program  during  parsing  and  for  subsequent  manipulations.  The  ast  structure  stores  die  minimal  amount 
of  information  necessary  (unlike  parse  trees).  E^h  abstract  syntax  tree  is  composed  of  operator  and 
argument  (operand)  nodes  (Hgure  9).  In  an  ast,  the  operator  is  found  at  an  interior  ruxle  and  the  operands 
are  foe  children,  or  leaves,  of  foe  operator.  Attributes  determined  during  parsing  are  stored  in  foe  iKxles. 
TIk  ast  structures  are  built  up  during  parsing  to  represent  foe  statements  in  foe  program.  In  foe  case  of 
IMPORT,  they  store  statements  found  in  method  bodies.  These  sequences  of  statements  take  the  form  of 
ordered  lists  of  ast  nodes. 

Eadi  operator  and  argument  iKxle  contains  an  operator  and  an  ordered  collection  of  operands,  where 
eadi  operand  is  an  operator  and  argument  node.  Bgure  10  shows  the  class  diagram  for  foe  ast.rxxle.  The 
op  attribute  stores  foe  paiticular  operator  of  the  ast  node.  These  are  the  arithmetic,  relational,  boolean, 
keywords,  built-ins,  etc.,  of  the  language  definition.  The  method  and  obj_instance  attributes  are  only  used 
(valid)  for  certain  method  invocations.  The  wtdch.type  attribute  is  a  pointer  to  an  instance  of 
type.exixessionjist  and  stores  the  type  of  foe  operator.  The  final  attribute  is  a  union  stnicture.  This 
structure  holds  the  semantic  value  or  meaning  of  the  operand.  This  includes  the  basic  types,  symbol  table 
entry,  or  a  list  of  operands  for  foe  iKxle.  There  are  constructors  for  the  class  that  create  each  of  the 
possible  different  ast  ruxle  types. 
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idl_Clau 


op ;  operator 

rriiich.lype  :  type_expreasioo_lut 
m^wd :  aymtab.oitiy 
obj_iiiitaiioe  ;  ast.node 
lemantic.value  :  union  stnichire 


Figure  10.  Class  Diagram  of  aat_iiode. 


Blodc  node 


Declaration  Abstract  Syntax  Tree 

Figure  11.  A  Blodt  Node  With  Declaration  Object. 

There  are  other  useful  attributes  ttuit  can  be  included  in  the  ast.node  class  to  su{^rt  the 
development  of  software  tools.  They  may  keep  pointers  to  sections  in  the  source,  or  the  source  itself  at 
this  level.  This  is  to  help  with  qrplications  like  structure  editors  and  debuggers.  Relevant  sections  of  code 
can  be  accessed  in  ttiis  way.  oito  bookkeefring  information  can  be  stored  at  this  level  for  such  tools  as 
run-time  {xofilers. 

The  ast  apfuoach  is  used  to  imjriement  the  BLOCK  statement  in  IMPORT  (Figure  1 1).  IMPORT 
is  a  lexically  scared  language,  and  wittiin  a  method  or  block,  foe  BLOCK  construct  permits  the  definition 
of  a  new  so^.  Hence,  foe  block  node  must  keep  track  of  the  new  envircMunertt  in  \riiidi  the  contained 
statements  must  be  executed.  This  is  accorrqrlisbed  by  {dacing  a  Declaration  object  as  the  first  operand 
in  the  operand  list  of  foe  ast_node. 

Supporting  Classes 

A  number  of  classes  are  needed  to  support  foe  SEE  classes  in  compilation  of  IMPORT  modules, 
code  gmeratimi,  and  development  of  software  tools.  These  classes  have,  necessarily,  bear  referred  to 
above  in  cmijunction  with  the  presentation  of  die  SEE  classes. 

Type  Expression  and  Type  Expression  List  The  IMPORT  compiler  must  perform  static  type 
cheddng  of  foe  source  code  modules.  IMPORT  is  a  strongly  typed  language  aid  static  type  diecl^ 
he^  eiuure  {MOgram  correctness.  Static  diecking  ensures  that  types  produced  by  language  constructs 
madL  A  type  erqnession  is  the  type,  as  defined  by  foe  language’s  type  system,  produced  by  some 
language  construct  In  IMPORT,  fom  is  a  set  of  basic  sui^lied  types,  e.g.,  INTEGER,  and  user-defined 
types,  e.g.,  OBJECT.  Many  ofoer  constructs  have  t^  expressitm  associated  with  them,  for  example, 
mefoods  that  return  a  value  and  built-in  functkxis.  Hgure  12  shows  foe  type.expressicm  class. 
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_ _ type_e]tpies«ion 

id-type :  alomic.type 
aniy_8ize :  integer 
ki_claM :  «ymttb_aitry 

» :  operalor(Q^_expfettion) 


Figure  12.  The  type_eiq>ression  Class. 


Figure  13.  The  Declaration  and  Scope  Classes. 


This  simple  class  contains  attributes  for  storing  the  type  of  a  language  construct  The  attribute 
id_type  stores  die  basic  language  defined  types  such  as  BOOLEAN,  INTEGER,  etc.  If  the  type  is 
OBJECT,  then  the  id.class  attribute  refers  to  its  symtab_entry.  Tire  anray_size  attribute  stores  the  size  of 
a  Q^ie  declared  as  an  ARRAY  is  valid  only  for  this  type.  In  addition  to  constructor  ami  destructor 
methods,  type.exinession  has  an  operator  method  for  testing  equality. 

The  type_expiession_list  inherits  from  id_oodb_list  and  stores  a  collectimi  of  type.expression  object 
instances.  It  has  methods  for  operating  on  Q^_expressionJist  such  as  comparing,  copying,  and 
appending.  It  is  used,  for  example,  to  pass  mediod  aigumoit  lists. 

Declarations  and  Scones.  Declarations,  such  as  of  variables  in  a  programming  language,  associate 
information  with  the  name  of  die  declared  otyect  This  informadon  is  us^  widiin  the  context  of  the  scope 
rules  of  die  language  to  determine  if  and  when  a  name  is  valid  and  how  it  can  be  manipulated.  The 
section  of  code  (program  text)  in  whidi  a  declaratitm  is  valid  is  called  a  scope.  IMPORT  is  a  Mock 
structure,  lexically  scoped  language.  During  compilatitm,  a  symbol  table  oitty  is  created  in  the  symbol 
ttdde  m  encountering  a  new  declaration  within  a  scope. 
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The  Declaration  class  contains  pointers  to  tlK  smallest  enclosing  scope:  the  local  scope.  This  scope, 
witfi  all  its  ancesUMS,  whidi  represent  other  enclosing  scq)es,  constitute  the  current  ravironment  for  a 
lexically  sc(^)ed  language.  The  Declaration  class  contains  an  attribute  diat  is  a  reference  to  a 
syn)tab_eittry_list  The  object  referred  to  here  is  Ae  set  of  declarations,  stmed  in  the  symbol  table,  diat 
are  widiin  the  local  scope.  (This  structure  is  necessary  to  nm  an  interpreter  using  the  intermediate 
representatimi  of  die  {mgram.) 

The  Sc(^  class  is  used  to  manage  declaradmis  within  a  scope.  It  ccmtains  a  reference  to  the 
previous  oiclosing  scope  and  the  depth  of  the  current  scope  within  the  context  of  the  environment  It  has 
a  list  of  declarations  within  die  scope,  and  a  local  symbol  table  is  provided  for  their  access.  The  local 
symbol  table  is  implemented  as  an  opoi  (no  limit)  hash  table  of  entries,  with  oie  symbol  table  entry  per 
identifier.  These  entries  contain  all  tte  semantic  and  type  informatimi  for  that  identifier.  Figure  13  shows 
the  relation  of  the  Declaration  class  to  the  Scope  and  symtab_entiy_list  classes. 

The  Symbol  Table  and  Symbol  Table  Entries.  A  symbol  table  is  used  to  manage  declaratimis  and 
their  scopes  as  diey  are  encountered  in  modules  and  for  code  generatimi.  The  symbol  table  is  organized 
as  a  directed  acyclic  gra|^  of  scopes,  whose  root  (there  being  only  one  top  level  node)  is  the  global 
environment.  Immediately  below  this  level  is  a  collection  of  scopes  fm  each  individual  programming 
tiKxhile.  Each  entry  in  the  symbol  table,  actually  in  the  {qjpropriate  xope,  corresponds  to  die  name  of  a 
declaration.  Access  to  declarations  is  efficiently  implemented  by  hashing  on  the  spelling  (characters 
making  up  the  name)  of  the  declaraticMi.  The  Symtab  class  is  shown  in  Figure  14.  Its  relation  to  the 
Sc(^  and  symtab.entry  class  is  ^wn  in  Figure  IS. 

Finally,  die  symtab.entry  class  contains  the  infcmnation  associated  with  a  named  declaration.  It 
Stans  the  name,  the  generated  name  (for  code  generation),  the  symbol  type,  and  other  information  (Figure 
16).  It  also  constrains  references  to  instances  of  id.Qass,  id.Method,  imd  type_expression_list.  These  are 
needed  for  access  to  complex  symbol  table  entries  such  as  objects,  medio^,  type  names,  and  variables. 

In  addition,  the  symbol  table  also  keeps  track  of  a  '‘use  list”  for  each  variable  (stored  in  a 
symtab_entry  instance).  The  list  keeps  track  of  the  blocks  or  sections  of  die  parse  tree  where  a  variable 
is  used.  This  is  a  service  provided  to  supptat  other  tools,  like  stmcture  editors  and  interjneters  diat  can 
use  diis  information  to  help  die  programmer  maintain  consistency  when  a  variable  declaration  is  changed. 


Lexer,  Parser,  and  Semantic  Controller 

The  presentation  of  die  SEE  classes  in  the  previous  section  explained  the  Object  Model  suppmting 
both  die  analysis  ai^  syndiesis  phases  of  the  IMPORT  compiler.  This  secticm  describes  die  tools  used 
to  construct  tte  compiler,  and  odier  classes  developed  for  the  analysis  fdiase,  and  relates  diem  to  the  SEE 
classes.  As  described  earlier,  the  analysis  potiai  of  die  cmnpiler  consists  of  the  lexer,  parser,  and 
semantic  controller.  Hgure  17  ^ws  a  schematic  of  the  components  of  the  analysis  i^iase. 

The  lexer  and  parser  for  the  IMPORT  con^iiler  was  built  using  Con^iiler  Resources’  Yacc-H- 
(Revision  1.4).  Yacc-H-  is  an  advanced,  object-oriented,  language  construction  tool  written  in  C-H-.  The 
objects  in  dadied  boxes  in  Hgure  17  are  ctmipcments  from  the  Yacc-H-  Language  Objects  Library  (LOL). 
The  “lexer”  is  more  than  die  usual  deterministic  finite  automata  (DFA)  lexer,  and  is  specified  in  terms  of 
productions  much  as  the  parser  is  specified.  This  allows  nested  comments  that  would  odierwise  not  be 
possible  in  a  standard  DFA.  The  parser  produced  by  Yacc-H  is  a  table-driven  LR(1)  parser  supmor  to 
the  commonly  available  Unix  yacc  LAIJl  implementation.  Hie  accompanying  reference  manual  fiilly 
describes  the  LOL  classes  (Compiler  Resources  1992). 
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Symtab 


globaLfcope :  scope 
cuneaLScope :  scope 
Cumnonodule ;  scope 
cunenLobject :  symtab.entiy 


eiilei_new_scope 

eiiier_object_soope 

Leave_scope 

lnsert_var 

iiisefC.coast 

inse(L.object 

inseonethod 

iiiseit_imported 

iiiipart_d«ae_symbol 

is_in_object 

is.iiusupefclass 

is_io_|iiodule 

is_m_soope 

is_naine_iiiLacope 


Figure  14.  The  Sjmtab  Clan. 


Figure  15.  Relation  of  Symtab,  Scope,  and  aymtabjentry  Classes. 


This  sectron  describes  the  id_seniantic_c(Mitroller  class  and  its  lelaritHi  to  the  SEE  classes  and  die 
object  iqxisitoiy.  The  semantic  acdtm  code  and  the  SEE  classes  are  written  in  C^.  The  header  files  for 
di^  classes  are  listed  in  Appendix  C.  The  soiantics  actitms  detomined  during  parsing  result  in  method 
invocadoos  mi  an  instance  of  id.semandc.controller.  This  object  uses  the  SEE  and  associated  siqipoit 
classes  to  ocmstnict  the  intermediate  iqnesentatkm  of  the  module  being  comjnled.  The  intermediate 
rqxesentadmi  is  stcued  in  an  object  repository  created  by  use  of  die  GOOD  interface  (described  in 
Genaic  Object-Oriented  Database  Interfkce,  p  52). 

Rgure  18  shows  the  id_semantic_controller  class.  It  contains  idtributes,  mosdy  pointos  to  object 
instances,  deteimined  by  the  state  of  die  parser.  It  maintains  refnences  to  die  current  module,  object,  and 
mediod  for  wdiidi  it  is  amstiucting  the  iidermediate  rejHesenatimi.  Most  of  the  mediods  of  this  class  are 
of  die  fimn  id_semantic_contiDller ::  build.X,  ^Miere  X  is  a  ccmstnia  of  die  language.  Thoe  is  a  medud 
of  die  dass  for  all  constructs.  These  are  called  by  the  parser  uriiai  it  determines  die  crnffitiucL 
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symtab_entry 


symboLpame  ;  character 
generatecLpaine  :  character 
symboUype  ;  enumeration 
uaejiat ;  astJiat 

slorage_lype :  type_expTessioit_list 

object :  kLCIass 

method  ;  kLrnethod 

parmJojtype :  parm_io_types 

uaejist :  astjiode 

ia_privale  :  boolean 

iajMatic  :  boolean 


Figure  16.  The  syintab_entry  Class. 


Not  brought  out  in  the  discussion  of  the  SEE  classes  is  the  aiq)earance  of  the  id_oodb_list  class  as 
attributes.  This  class  is  heavily  used  in  the  implementation  as  it  provides  support  for  storage  of  lists  of 
persistent  objects.  This  is  one  of  the  classes  of  the  GOOD  interface.  Several  of  the  SEE  classes  inherit 
from  id_oodb_list.  These  are  ast_liat,  type_expression_list,  and  symtab_entiy_list.  It  is  through  the  use 
of  these  classes  and  persistent  object  allocation  functions  of  the  GOOD  that  i<i_semantic_controller  builds 
dre  persistent  intermediate  representation. 

A  separate  lexer  and  parser  was  also  created  for  DOME  to  produce  the  intermediate  form  of  the 
declarative  code  found  in  KNOWLEDGE  modules.  This  parser  was  constructed  with  the  same  tools  as 
the  IMPORT  parser  described  above.  Yacc'H-  provides  fm*  the  collaboration  of  these  two  distinct  parsers 
within  a  single  af^licadon. 


Code  GcBcrator,  Compiling,  and  Linking 

It  was  decided  that  the  code  generator  should  produce  C-h-  code  for  a  number  of  reasons.  Since 
it  has  replaced  C  as  the  de  facto  systems  programming  language,  there  is  a  close  mapping  between  the 
constructs  found  in  IMPORT  and  C-H-.  This  greatly  facilitates  code  generation.  Features  such  as 
inheritance,  and  operator  and  method  overloading,  for  example,  are  much  easier  to  achieve.  This 
significantly  reduced  the  amount  of  effort  needed  to  quickly  get  the  language  running,  especially  when 
conqiared  to  generating  machine  instructions  directly.  This  approach  should  also  provide  for 
cross-platform  portability. 

The  code  generator  produces  C++  code  from  the  intermediate  representation  stored  in  the  object 
repository.  It  takes  as  input  commands  the  specification  of  a  path  to  toe  rqiository  and  toe  name  of  a 
rttodule  or  a  key.  The  class  id_code_generator  performs  toe  reverse  qieration  of  id_semantic_controller 
of  the  last  section.  It  has  basically  toe  same  attributes  and  jm  id_code_generator  ::  generate_jX  method 
where  X  corresponds  to  a  languge  construct.  This  class  performs  a  pre-order  traversal  of  toe  intermediate 
representation  to  produce  the  corresponding  C-h-  code  for  each  ast  node.  It  is,  however,  specific  to 
IMPORT  since  it  requires  knowledge  of  toe  persistent  class  libraries,  and  toe  IMPORT  runtime  libraries 
to  genmate  toe  code  required  by  each  of  them.  It  also  produces  toe  C++  statements  to  create  toe  structures 
retpiired  the  theorem  prover  at  runtime. 

Conqiiling  and  linking  is  pofoimed  in  toe  usual  manner.  The  software  engineering  environment 
tools  to  support  toe  process  of  generating  the  correct  version  of  an  q)plication  as  well  as  assisting  in 
compiling  of  IMPORT  programs  is  described  in  Quqrter  4. 
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Figure  17.  Congranents  of  the  Analysis  Phase. 
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id_Knuatic_coQtToUer 

currenumoduk :  kLModule 
importedLmodule  ;  kl_Module 
cunau_ined>od :  id_Metfaod 
P>nn_io_type :  mummtion 
cuntnmMnn_naiiies  ;  lymtab.entry  Jist 
curmu_pann_type :  type_expressioa_list 
cuiient_iiiediods :  id_oodb_list 
current_du<es :  kl.oodbjut 
cunent_teU_m«hod9  ;  id_oodb_!ist 
is_public  :  boolean 
ia.overridden  :  boolean 

import_Module 

build.... 


F^re  18.  The  id_seiiiaiitic_controller  Class. 


The  DOME  Runtime  Interpreter  Interface 

A  goal  of  IMPORT/DOME  is  to  provide  the  ability  to  make  design  trade-off  decisions  between  the 
efficiency  of  imperative  code,  and  die  intuitiveiiess  of  d^larative  code.  The  integration  between  the  two 
programming  styles  is  achieved  through:  shared  data-types  and  data  structures.  This  is  done  by  having 
a  common  symbol  table,  runtime  type-checking,  and  direct  manipulation  of  objects  in  the  object  repository 
by  the  DOME  theorem  prover. 

Launching  a  Query 

The  DOME  theorem  prover  is  starts  whenever  a  QUERY  method  of  an  object  is  invcdced.  At 
compile  time,  each  QUERY  mediod  invocadcm  is  translated  into  a  call  to  the  themem  prover  with  the 
appn^ate  expression  denoted  by  the  method  and  its  parameters.  An  expression  structure  that  can  be 
used  by  die  theorem  prover  is  built  at  runtime  into  the  object  repositmy  or  a  runtime  database.  The 
theorem  {xover  then  attempts  to  unify  the  expression  with  the  knowledge  base  of  die  object  whose  method 
was  invcdced. 

QUERY  mediods  must  have  a  mechanism  to  permit  than  to  communicate  values  found  in  die 
impoative  (conqiiled)  code  to  the  knowledge  base.  They  must  also  return  values  from  the  knowledge  base 
to  variables  locr^  in  imperative  mediods.  This  is  done  by  passing  parameters  as  arguments  to  QUERY 
methods.  If  a  parameter  is  designated  as  an  INOUT  parameter,  die  diemrem  prover  can  assign  a  value  to 
it  (whoi  it  successfully  unifies  the  QUERY  expiessicm).  This  permits  die  value  to  be  assigned  to  a 
variable  in  die  imperative  code. 

Shared  Data-Types  and  Data  Structures 

To  reduce  data  impedance  between  the  themem  inuver  and  the  compiled  code,  two  data-types 
(enumerated  types  and  USTs)  are  Glared.  These  Qrpe  structures  may  be  accessed  by  both  the  compUed 
code  and  die  theorem  prover.  Odm-  first  class  data-types:  INTEGERS,  REALs,  STRINGS,  and  CHARs, 
can  also  be  passed  as  arguments  to  the  themem  prover.  This  necessitates  an  UNINSTANTIATED  value 
fat  all  variabtes,  so  that  diey  may  contain  the  results  of  unificatiai  returned  by  the  theorem  prover. 
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The  use  of  a  ^rsistent  object  repository  or  a  nintime  database  allows  the  theorem  prover  to  be 
disassociated  with  the  con^>iled  code,  so  it  can  run  as  a  separate  process,  and  interact  with  compiled  code 
only  through  the  persistoit  database  and  perhaps  an  inter-process  socket.  Several  ^plications  could  be 
served  in  this  manner,  (mt  peiiuq>s  several  different  interpreters  with  different  unification  strategies  could 
be  used  by  a  single  application. 

Enumerated  Types.  Traditionally,  symbols  in  an  interpreted  Prolog-like  language,  such  as  DOME, 
have  no  semantics  beyond  the  fact  that  they  can  be  used  to  satisfy  sonw  unification  rule.  In  IM¬ 
PORT/DOME,  all  symbols  that  may  be  returned  or  used  in  imperative  code  have  to  be  declared  as  part 
of  an  enumerated  type.  Hence,  each  symbol  is  associated  with  a  type  and  an  ordinal  value.  These 
semantics  are  very  important  since  the  result  of  a  unification  can  now  be  used  in  comparisons  or  as  array 
indices  in  imperative  code. 

Lists.  LISTS  are  basic  structures  in  the  theorem  prover.  All  expressions  that  the  theorem  prover 
manipulates  are  LISTs.  LISTs  are  first-class  data-types  in  IMPORT/DOME  and  may  be  passed  as 
parameters  to  QUERY  methods  and  received  as  results  of  a  unification. 

Runtime  Tvoe-Checking.  Since  the  symbol  table  from  the  imperative  code  is  stored  in  a  object 
repository,  runtime  type  information  is  available  to  the  themem  prover.  This  means  that  after  a  symbol 
has  been  unified,  the  theorem  prover  can  use  the  symbol  table  to  find  the  relevant  type  information  and 
check  to  see  if  it  is  of  the  type  expected  for  die  parameter  of  the  QUERY  method.  If  there  is  no  type 
conflict,  then  a  successful  u^ication  is  assumed,  and  the  semantic  value  of  the  symbol  is  returned. 

Direct  Manipulation  of  Object 

The  theorem  prover  should  go  beyond  reasoning  about  the  fixed  set  of  clauses  in  the  knowledge 
base  of  the  local  object  (die  object  whose  QUERY  method  launched  the  computation).  It  should  be  able 
to  provide  different  solutions  based  on  some  current  state  of  the  world.  This  state  would  presumably  be 
provided  by  the  data  members  of  the  local  object  and  some  other  objects  “known”  to  the  local  object. 
Since  these  objects  can  be  stored  in  a  database,  they  are  accessible  to  the  theorem  prover,  which  can 
translate  their  state  into  some  form  suitable  for  unificatimi. 

• 

This  aspect  of  the  language  is  still  under  investigation,  and  it  has  not  been  determined  how  we  can 
“introduce”  one  object  to  another  so  that  the  first  object  may  use  the  second  object’s  state  in  the  reasoning 
process.  Current  (miposals  include  the  use  of  automatically  created  class  extents,  from  which  an  object 
may  find  a  relevant  instance  that  should  be  included  in  its  knowledge. 


Simulation  Runtime  Support 

This  sectirm  describes  the  runtime  system  for  the  IMPORT  language,  which  is  a  sequential 
implementation  for  single  processor  environments.  The  runtime  libraries  and  scheduler  were  developed 
using  the  AT&T  task  classes  and  collections  classes  from  the  tools. h-t-+  commercial  package  produced 
by  Rogue  Wave  Software  (1992).  Rogue  Wave  allows  the  binary  libraries  to  be  distributed  as  part  of 
another  tqqilication  without  restriction. 

Semantics  of  Simulation  Constructs 

The  design  of  the  runtime  system  is  motivated  by  the  requirements  of  the  simulation  time  passing 
and  synchnxiizatirm  constructs  of  IMPORT.  The  semantics  of  each  of  these  constructs  is  described  below. 
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SIMTIME.  SIMTIME  returns  die  current  time  according  to  a  user-defuied  simulated  scale. 


TELL  Method  Invocations.  Each  TELL  method  invocation  results  in  the  creation  of  a  new  thread 
of  control,  which  semantically  is  assumed  to  exist  ccmcurrently  (in  simulated  time)  with  the  activation 
that  made  the  invocatioi.  Furtlrermore,  this  new  thread  of  control  may  or  may  not  become  synchronized 
with  some  other  thread  of  control  executing  in  the  system,  depending  on  the  nature  of  the  invocation 
mechanism.  Thus,  the  runtime  system  must  provide  supprnt  fn'  creati(xi  of  an  asynchronous  thread  of 
ctMitrol  (which  executes  the  code  body  of  the  TELL  method),  and  allow  for  subsequent  synchixMiization 
of  this  thread.  The  synchrcmization  constructs  provided  in  the  IMPORT  language  take  the  fcmn  described 
below. 

WATT  DURATION  Statements.  Simulation  time  elapses  by  the  execution  WATT  DURATION 
statements,  which  cause  the  current  thread  of  control  to  yield  ccmtrol  to  another  ready  thread  and  to 
resume  executitm  either  when  the  specified  duradtMi  of  simulated  time  has  elapsed,  or  if  the  wait  is 
interrupted.  The  language  allows  different  actions  to  be  specified  depending  on  the  cause  of  the 
resumption.  Thus,  the  runtime  system  needs  to  provide  support  for  suspending  executing  threads,  and 
resuming  at  different  points  in  the  code. 

WATT  FOR  (TELL  Method  Invocation).  This  is  one  of  the  synchronization  constructs  provided  in 
the  language  that  allows  the  invoking  thread  to  wait  for  the  termination  of  the  invdced  thread.  A  thread 
is  assumed  to  have  terminated  when  its  execudtm  encounters  a  return  from  the  corresponding  method 
body.  The  language  allows  the  wait  to  be  interrui^ed  by  the  following  ctmstructs,  which  requires  the 
runtime  system  to  provide  suppmt  similar  to  that  required  for  die  WATT  DURATION  statement  A  record 
of  the  activity  (waiting  for  a  duraticm  of  simulation  time  to  elapse,  or  for  another  TELL  method  to 
terminate)  ne^  to  be  kept  that  associates  the  waiting  thread  with  the  activity  it  is  waiting  upcxi.  Since 
both  WATT  FOR  and  WATT  DURATION  statements  can  also  appear  in  ASK  methods,  the  notion  of  a 
thread  needs  to  be  well  defined  so  as  to  reccHd  all  activities  h^ipening  as  part  of  the  same  thread  at  the 
same  place. 

WATT  FOR  TRIGGER  To  Fire.  This  is  another  synchnmizatitni  construct  used  to  synchronize  a 
group  of  threads.  All  threads  wait  on  a  special  runtime  object  called  the  Trigger  and  resume  qperaticm 
when  another  thread  executes  the  Rre  method  of  die  Trigger  object.  Sui^iort  similar  to  the  previtMis 
statement  needs  to  be  provided  in  the  runtime  system. 

INTERRUPT  and  INTERRUPT ALL.  The  language  provides  constructs  for  asynchronously 
resuming  a  thread  of  control  that  is  either  waiting  fn-  a  duration  of  simulated  time  to  elapse,  or  is  waiting 
for  the  terminatiai  of  another  thread.  The  interrupted  thread  is  specified  by  the  TELL  method  name 
associated  with  the  thread,  and  the  object  instance  on  which  the  method  has  been  invoked.  This  requires 
tire  runtime  system  to  categorize  the  different  thread  activities  by  the  type  of  the  TELL  method.  The 
semantics  of  the  INTERRUPT  constructs  specify  diat  the  diread  to  be  resumed  is  the  one  that  is  likely  to 
resume  the  earliest,  provided  its  wait  is  not  interrupted.  Thus,  some  noticm  of  when  an  activity  is  likely 
to  complete  ^ould  ^so  be  present  in  the  activity  records. 

TERMINATE.  A  thread  terminates  itself  when  it  executes  the  TERMINATE  statemoit  The 
runtime  system  needs  to  ensure  that  when  a  thread  terminates,  the  TERMINATE  is  prqiagated  recursively 
to  all  threads  that  are  waiting  cm  this  thread. 
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Details  cf  the  Implementation 

The  runtime  system  has  been  built  using  the  AT&T  task  library,  which  im)vides  support  for  the 
management  of  lightweight  threads  of  control.  Figure  19  shows  the  overall  structure  of  the  runtime 
system. 

The  encapsulated  tegirm  shows  die  fiinctirmality  that  the  AT&T  tasking  package  in-ovides;  it  takes 
care  of  scheduling  threads  that  are  not  waiting  on  other  activities,  llie  suspension  and  resumption  of 
threads  that  are  effected  by  switching  die  ccmtexts  of  two  threads  are  all  provided  by  the  task  library. 

A  thread  gets  created  whenever  a  TELL  method  is  invoked.  The  different  activities  correspond  to 
the  executitm  of  WATT  DURATION  and  WATT  FOR  statements.  The  main  comptments  of  the 
implementation  are  discussed  below. 

Activity  Records.  To  ensure  uniform  treatment  of  both  WAIT  DURATION  and  WATT  FOR 
activities,  the  implementation  treats  the  activity  conespcmding  to  WAIT  DURATION  also  as  being  an 
activity  that  is  waiting  for  a  thread  to  terminate.  This  effect  is  achieved  by  creating  a  Timer  thread  that 
terminates  after  waiting  fm*  the  specified  duration  of  simulation  time  to  elapse.  Thus,  all  activities  initiated 
from  threads  created  as  a  result  of  user-specified  TELL  methods  wait  for  the  termination  of  either  Timer 
threads,  or  other  user  threads. 

Each  activity  record  has  three  fields:  an  identifier  for  the  thread  requesting  the  activity,  the  thread 
being  waited  upon,  and  an  estimate  of  the  time  when  the  activity  is  likely  to  complete.  It  is  possible  to 
accurately  record  the  termination  time  for  WATT  DURATION  activities;  however,  WATT  FOR  activities 
do  not  lend  themselves  to  a  similar  situation.  The  implementation  sets  the  estimated  time  for  termination 
of  WATT  FOR  activities  to  be  set  to  the  time  of  initiatimi  of  the  activity. 

Activity  Table.  Whenever  an  activity  is  initiated,  an  activity  record  gets  stored  in  the  Activity  Table 
cmrespmiding  to  the  thread  that  initiated  the  activity.  Activity  T^les  associate  all  the  activities 
corresponding  to  threads  created  by  TELL  method  invocations  on  a  particular  object  These  activities  are 
categorized  by  the  name  of  the  TELL  method  that  creates  the  thread.  Furthermore,  the  activities  are 
ordered  with  respect  to  the  estimate  of  their  termination  times. 

Activity  Tables  are  queried  whenever  the  activities  corresponding  to  a  TELL  method  of  a  particular 
object  are  interrupted  via  the  INTERRUPT  or  INTERRUPT-ALL  statements. 

Task— Activity  Table  Associations.  It  is  important  to  urulerstand  what  it  means  to  interrupt  an 
activity  conesptHiding  to  a  TELL  metiiod  invocatitm  on  a  particular  object.  TELL  method  invocations 
create  threads,  which  in  turn  iiutiate  activities  whenever  WATT  DURATION  and  WATT  FOR  statements 
are  executed.  Note  that  these  statements  could  be  encountered  in  the  body  of  the  TELL  method  whose 
invocation  created  the  thread,  or  any  ASK  method  that  was  invoked  from  this  TELL  method.  A 
distinction  needs  to  be  ma^  between  the  Activity  Table  of  the  object  whose  method  is  being  currently 
executed,  and  the  Activity  Table  of  the  object  whose  TELL  method  invocation  created  the  thread.  All 
activities  initiated  by  a  thread  should  be  stored  in  the  Activity  Table  corresponding  to  the  latter.  Since 
the  infmmation  about  die  parent  class  of  the  TELL  method  is  lost  once  we  exit  the  scope  of  the  TELL 
method  body,  infemnatitm  about  the  proper  Activity  Table  to  record  all  activities  in  must  somehow  be 
inferred  givoi  die  thread  identifier.  The  Task-Activity  Table  Associations  reemd  this  relationship. 

List  of  Garbage  Ta.sks.  Reclamatimi  of  storage  allocated  to  threads  and  their  entries  in  the  various 
tables  is  an  important  issue.  Storage  corresponding  to  threads  created  as  a  result  of  WAIT  FOR  activities 
is  very  easy  to  reclaim:  the  storage  is  returned  to  the  heap  when  control  returns  to  the  initiating  thread. 
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Figure  19.  Overall  Structure  of  the  Runtime  System. 

However,  asynchronous  invocations  of  TELL  methods  pose  a  problem,  since  there  is  no  way  of  detecting 
when  these  invocations  terminate.  The  implementatitm  sui^its  a  primitive  garbage-collection  facility, 
which  consists  of:  (1)  recording  the  creation  of  a  thread  due  to  an  asyrx;hronous  invocation  of  a  TELL 
method,  (2)  moving  of  the  thread  to  a  list  of  garbage  tasks  whenever  the  thread  terminates  (done  by  tte 
thread  itself),  and  (3)  releasing  the  storage  associated  with  terminated  tasks,  whenever  the  garbage  task 
list  is  found  not  to  be  empty. 

The  association  tables,  and  the  sorted  list  of  activities  stored  in  the  Activity  Table  have  been 
implemented  using  the  classes  provided  by  the  Rogue  Wave  Qass  Lilmury. 

The  main  protocols  used  in  the  implemoitation  are  described  below.  A  thread  starts  executing  under 
the  control  of  the  AT&T  task  library  whenever  a  class  derived  from  the  base  class  task  is  instantiated. 
A  diread  waits  on  other  threads  by  invoking  a  method  of  class  task,  resultis  ().  This  causes  the 
initiating  thread  to  get  stored  in  the  list  of  pending  threads  at  the  initiated  thread.  When  the  initiated 
thread  terminates,  all  pending  threads  are  activated. 

Initiatinrr  an  Activity.  An  activity  record  is  created  and  inserted  into  die  Activity  Table 
corresponding  to  the  initiating  thread.  The  initiating  thread  then  synchronizes  with  the  initiated  thread 
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using  Ac  resultis  ( )  meAod.  The  status  of  the  resultis  ( )  call  can  be  used  to  determine  whether 
a  particular  activity  completed,  was  interrupted,  or  encountered  a  TERMINATE  statemrat.  In  all  cases, 
the  storage  associated  wiA  Ae  initiated  thread  is  returned  to  heap  after  control  returns  to  Ae  initiating 
thread. 

Termmating  a  Thread.  When  a  thread  executes  a  TERMINATE  statement,  it  causes  all  calls  to 
resultis  ( )  for  this  thread  to  return  a  status  indicating  that  it  was  terminated.  This  status  has  the  effect 
of  recursively  termiruiting  all  threads  Aat  were  pending  on  a  terminated  thread. 

Interrupting  an  Activity.  The  semantics  of  Ae  INTERRUPT  and  INTERRUPT-ALL  statement  call 
for  mterrupting  an  activity  corresponding  to  a  specified  TELL  meAod  invocation  of  a  particular  object. 
The  activity  to  be  interrupted  is  obtained  by  looking  up  Ae  Activity  Table  and  picking  up  Ae  most 
imminent  activity  categorized  under  Ae  specified  TELL  meAod.  If  Ae  activity  corresponds  to  waiting 
on  a  Timer  thread,  then  it  can  be  interrupted  outright,  and  Ae  space  reclaimed.  However,  if  Ae  activity 
corresponds  to  waiting  for  Ae  termination  of  anoAer  user  thread,  the  semantics  of  INTERRUPT  need  to 
be  recursively  propagated  to  this  thread.  Only  when  all  threads  being  awaited  for  have  been  interrupted, 
can  Ae  space  corresptmding  to  a  particular  thread  be  reclaimed. 

The  implementation  provides  all  the  runtime  fimctionality  through  a  set  of  macros  Aat  are  called 
in  the  generated  code. 

Code  Generation 

In  addition  to  Ae  use  of  Ae  runtime  macros  whenever  Ae  IMPORT  statements  Ascussed  in  Ais 
section  are  encountered,  Ae  following  changes  are  required  to  generate  code  that  can  use  the  AT&T  task 
library: 

•  Each  TELL  meAod  prototype  is  changed  to  return  (task  * )  instead  of  void.  The  returned 
thread  pointer  is  used  in  Ae  nmtime  macros  to  perform  synchronizations  on  threads. 

•  The  body  of  each  TELL  meAod  is  moved  from  Ae  original  meAod  definition  in  Ae  enclosing 
class  to  Ae  cmistructor  of  a  new  “  TELL  meAod  class”  which  is  derived  from  class  task.  This 
is  the  essential  mtetface  wiA  Ae  AT&T  task  library  Aat  is  required  to  create  a  lightweight  task 
whenever  a  TELL  meAod  is  invoked.  The  original  TELL  meAod  definition  is  changed  to  a 
creation  statement  for  Ae  'TELL  method  class.” 

•  Each  ‘TELL  meAod  class”  constructor  is  enclosed  in  a  method_prologue  .  .  . 

EXiT_METHOD  body,  which  takes  care  of  setting  up  Ae  association  tables  and  reclaims  space 
on  exit. 

Extensions 

The  most  important  extensitm  to  Ae  runtime  system  that  has  not  been  currently  addressed  is  the 
integration  of  real-tinte  control  wiA  Ae  simulaticm  system.  This  can  take  Ae  form  of  a  grtqrhical  user 
mtetface  AtU  is  amtrolling  Ae  overall  simulation  system,  which  includes  Ae  user  as  one  of  its 
components,  and  which  might  inject  events  into  Ae  system. 

The  AT&T  task  library  provides  support  for  real-time  signal  handling  as  part  of  Ae  overall 
simulation  structure.  It  is  conceivable  that  this  be  extended  to  meet  Ae  requirements  of  Ae  above  task. 
The  overall  scheme  (which  needs  refinement)  for  doing  Ais  would  be  to  define  a  signal  which  models  Ae 
interface  wiA  the  external  world,  and  to  define  an  interruptHandler  task  Aat  contains  Ae  code  for 
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what  ought  to  haj^n  when  the  signal  does  crane  through.  User  (HPOgram  threads  need  to  wait  rai  this 
interruptHandler  task  after  they  have  finished  whatever  was  initiated  by  die  previous  event  that  was 
injected  into  the  system.  The  difficulty  is  two-fold: 

1.  Deciding  when  the  previous  event  has  fuiished  processing,  and  causing  all  the  user  tasks  to  wait 
upon  this  interruptHandler. 

2.  &isuring  that  the  processing  in  the  simulation  system  suspends  while  waiting  for  the  signal  to 
come  from  the  outside  world.  This  is  related  to  the  previous  point  since  nraiwaiting  threads  ^ould  not 
be  allowed  to  proceed  ahead  in  simulated  time. 


Generic  Object-Oriented  Database  Interface 

Object-Oriented  Database  Management  Systems  (OODBMS)  were  developed  to  support  application 
areas  that  need  to  model  complex  data  such  as  computer-aided  design  and  manufacturing,  and  software 
engineering.  The  IMPORT/DOME  language  system  integrates  object-oriented  procedural  and  declarative 
programming,  simulatirai,  and  persistent,  programming.  IMPORT  is  intended  to  be  part  of  an  integrated 
software  engineering  environment  Therefore,  it  must  provide  for  the  storage  and  manipulation  software 
objects  such  as  source  programs,  class  definitions,  libraries,  compiled  code,  and  intermediate 
representations  of  the  compiled  code  in  a  consistent  maimer  to  simplify  the  development  of  software 
support  tools.  The  availability  of  viable  CXDDBMS,  in  a  large  sense,  is  respraisible  for,  and  made  possible 
by  IMPORT/DOME.  Its  implementation  is  predicated  on  (X)DBMS  technology. 

Both  commercial  and  public  domain  OODBMS  were  investigated  for  use  as  the  underlying  database 
of  IMPORT.  From  the  beginning,  it  was  decided  not  to  tie  IMPORT  to  any  particular  existing  OODBMS. 
Users  of  IMPORT  with  access  to  a  commercial  OODBMS  may  want  to  use  it  as  the  underlying  database 
for  performance  or  other  reasons.  On  the  other  hand,  users  without  access  to  an  expensive  commercial 
OODBMS  may  want  to  use  a  {Hiblic  domain  system. 

Considering  the  above  factors,  IMPORT  was  (kssigned  with  a  common  OODBMS  interface  that 
provides  the  necessary  functionality.  The  interface  was  built  using  C++  and  craisists  of  classes  that 
provide  database  functionality  such  as  database,  directory,  set,  list,  tree,  set<ursor,  list-cursor,  tree-cursor, 
configuration,  workspace,  and  segment. 

We  have  already  hinted  at  the  need  for  a  common  interface  to  the  underlying  (X)DBMS.  The  need 
for  a  common  interface  to  the  underlying  OODBMS  of  the  system  is  explained  in  die  next  section. 
Following  that  is  a  description  of  the  database  classes  diat  craistitute  the  Generic  Object-Oriented  Database 
(GOOD)  interface.  This  chapter  craicludes  with  a  summary  of  the  current  status  of  and  plans  for  future 
work  in  this  area. 

Need  for  a  Common  Interface 

One  motivation  for  building  a  common  interface  to  the  underlying  (X)DBMS  of  the  IMPORT 
system  is  that  different  users  may  need  to  use  different  underlying  databases.  While  some  users  may  want 
to  use  a  commercial  database  because  of  performance  or  other  considerations,  other  users  may  want  to  use 
a  public  domain  database  for  cost  considerations.  By  not  tying  the  (X)DBMS  interface  to  a  specific 
database  system,  the  system  can  make  use  of  new  and  improved  CXDDBMS  systems  that  may  be  available 
in  the  fubue. 
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Another  motivation  for  providing  a  common  interface  is  the  need  to  support  persistence  with  the 
IMPORT  language  itself.  This  approach  permits  the  use  of  the  common  interfiu^e  as  the  mechanism  to 
achieve  persistence  in  IMPORT  in  a  consistent  manner,  and  to  provide  for  portabilitiy  as  well. 

The  common  interface  provides  a  mechanism  that  allows  the  differences  between  the  underlying 
database  implementations  to  hidden  from  the  user.  Features  that  are  in  the  common  interface  but  not 
in  the  underlying  database  can  be  built  on  top  of  the  database.  Also,  the  common  interface  can  be  made 
sinqtler  than  that  of  the  underlying  database  by  assuming  away  some  of  the  details  of  the  underlying 
database  system. 

Several  commercial  systems  were  reviewed:  ObjectStore  (Object  Design  1991),  the  ARPA  OpenDB 
(Wells,  Blakely,  and  Thompson  1992),  the  ITASCA  distributed  object  database  management  system 
(ITASCA  Systems  1991),  and  a  public  domain  database,  the  Object  System  of  STONE  (OBST) 
(Forschungszentrum  Informatik  1992).  The  ObjectStore  database  system  is  a  powerful  commercial 
OODBMS  that  provides  three  interfaces  to  the  database,  namely  a  C  interface,  a  C-h-  interface  and 
ObjectStore’s  proprietary  Data  Manipulation  Language  (DML)  interface.  It  has  a  variety  of  features 
including  collections,  sets,  lists,  bags,  versioning,  workspaces,  and  performance  features  like  clustering  of 
objects.  We  are  an  alpha  test  site  for  the  ARPA  OpenDB,  developed  by  Texas  Iitstruments,  and  have  only 
recently  begun  exploring  this  system,  but  its  open  design  and  modularity  seem  well  suited  for  our 
purposes.  The  Object  System  of  STONE  (OBST)  is  a  public  domain  system  which  provides  a  C++ 
inter&ce  to  the  OODBMS.  It  also  has  features  like  collections,  sets,  lists,  bags,  and  clustering,  but  lacks 
facilities  for  version  management  in  its  current  release.  A  special  and  useful  feature  it  provides  is  the 
directory  facility  that  can  be  used  to  manage  named  objects  in  an  UNIX-like  directory  hierarchy. 

The  GOOD  Common  Interface 

Based  on  a  review  of  existing  OODBMS  capabilties  and  interface  designs,  the  GOOD  was 
developed  with  the  hopes  of  spaiming  several  systems.  The  GOOD  common  interface  to  the  OODBMS 
of  the  IMPORT  system  was  specified  using  C++  classes.  Classes  such  as  database,  directory,  collection, 
set,  list,  tree,  list_cursor,  set_cursor,  tree_cursor,  segment,  configuration,  and  workspace  provide  the 
necessary  database  functiomdity.  The  main  functionality  of  the  various  classes  is  described  here; 
Af^iendix  D  contains  a  more  detailed  description. 

The  database  Class.  Databases  serve  as  stores  fm*  the  objects  created  by  an  application.  A  database 
is  created  by  sending  the  message  create  to  the  database  class.  Messages  such  as  “open”,  “close”, 
“lookjup”  are  available  for  opening,  closing,  and  looking  up  a  database  respectively.  A  database  object 
is  specified  as  a  parameter  to  the  persistent  version  of  the  C++  new  operator,  the  DNEW.  The  DNEW 
macro  has  syntax  and  semantics  similar  to  that  of  C++  new  operator,  in  that  it  takes  as  an  argument  a 
database  object  and  creates  the  new  object  in  the  specified  database. 

The  directory  Class.  The  “directory”  class  facilitates  naming  of  objects,  retrieving  of  named  objects, 
and  organization  of  named  objects  of  a  database  in  a  UNIX-like  directory  hierarchy.  A  database  is 
provided  with  a  root  directory  (“/”)  at  database-creation  time.  Other  directories  may  be  created  by  the 
^application  using  the  “mkdir”  message.  Messages  are  available  for  inserting  named  objects  into  directories 
(“insert'’),  retrieving  named  objects  (“lookup”),  and  removing  named  objects  from  directories  (“rm”). 

The  list  Class.  A  list  is  an  aggregate  object  whose  members  are  maintained  in  the  order  in  which 
they  were  inserted.  Messages  are  provided  to  facilitate  inserting  elements  in  the  beginning  or  at  the  end 
of  a  list  (“inseit_first”  and  “inseit_last”).  Selecting  all  members  of  a  list  that  satisfies  a  certain  predicate 
is  possible  using  the  “query”  message,  which  takes  as  argument  a  boolean-valued  expression  that  operates 
on  the  data  fields  of  the  members  of  the  list.  Members  of  the  list  that  return  true  when  the  boolean 


53 


expression  is  applied  to  it  are  returned  by  the  method.  A  cursor  type  called  “list.cursOT”  is  available  for 
iterating  over  Usts. 

The  set  Class.  A  set  is  an  aggregate  object  whose  members  are  not  maintained  in  any  particular 
order.  Messages  for  inserting  and  removing  elements  (insert  and  remove)  are  available.  A  query  message 
similar  to  the  one  in  the  list  class  is  available  for  the  set  class  also.  The  set_cursor  class  facilitates 
iteration  over  members  of  a  set. 

The  tree  Class.  The  tree  class  provides  a  mechanism  for  building  multiway  rooted  trees.  Most  of 
the  functionality  of  trees  is  provided  through  the  tree_cursor  class. 

The  list  cursor  CTass.  A  list  cursor  object  is  used  to  iterate  over  members  of  a  list.  It  is  created 
for  a  particular  list  object  using  the  create  message,  which  takes  a  list  object  as  its  argument  A  list  cursor 
object  points  to  the  first  element  of  the  list  initially.  Thereafter,  the  remaining  elements  of  the  list  can  be 
visited  in  order  by  sending  the  next  message  to  the  cursor.  Messages  last  and  previous  are  also  available 
to  traverse  the  list  in  the  reverse  order. 

The  set  cursor  Cla.ss.  A  set  cursor  object  is  used  to  iterate  over  the  members  of  a  set.  It  is  created 
for  a  particular  set  using  the  create  message,  which  takes  a  set  object  as  its  argument.  It  points  to  some 
arbitrary  element  of  the  set  initially.  Thereafter,  aU  the  elements  of  the  set  can  be  visited  by  sending  the 
next  message  repeatedly  to  the  cursor  until  the  cursor  points  to  a  null  object 

The  tree  cursor  Pass.  A  tree  cursor  object  is  used  to  traverse  a  tree  in  a  manner  des.ed  by  the 
user.  Like  the  list  cursor  and  set  cursor  objects,  a  tree  cursor  object  is  also  created  for  a  specific  tree 
object  A  tree  cursor  object  points  to  the  root  of  the  tree  initially.  Thereafter  the  user  can  traverse  the 
tree  using  messages  such  as  first _child,  next_sibling,prev_sibling,first_sibling,  and  parent.  Messages  are 
also  available  for  adding  children  to  a  node  of  the  tree  (add_child)  and  p^moving  leaves  from  a  tree 
(remove). 

The  confieuration  Class.  A  configuration  is  a  grouping  of  objects  that  evolve  at  the  same  time. 
In  other  words,  a  configuration  is  the  granularity  at  which  versioning  can  be  done  in  the  system.  An 
object  is  made  a  member  of  a  configuration  when  the  object  is  created  using  the  CTNEW  macro.  The 
C!NEW  macro  creates  an  object  in  a  configuraticHi  as  opposed  to  the  DNEW  macro,  which  creates  it  in 
a  database.  A  new  version  of  a  ccmfiguration  is  crea^  by  checking  out  a  configuration  to  a  private 
workspace  using  the  checkout  message,  and  checking  it  back  in  using  the  checkin  message.  This  model 
supports  versioning  of  the  latest  versions  of  a  configuration,  as  well  as  versioning  of  older  versions  of  a 
configuration,  thus  allowing  branching  version  sets  possible. 

The  workspace  Class.  Workspaces  allow  different  groups  of  users  to  perform  their  work  without 
interfering  with  each  other.  All  configurations  initially  belong  to  a  global  workspace.  A  global  workspace 
is  created  using  the  message  create jglobal  and  child  workspaces  are  created  using  the  message  create. 
Configurations  are  checked  out  to  the  child  workspaces  using  the  checkout  message  of  the  configuration 
class.  The  set_current  message  sets  a  woikspace  as  the  current  workspace.  Only  configurations  checked 
out  to  the  current  workspace  may  be  manipulated  by  the  user. 

The  segment  Class.  Segments  are  contiguous  chunks  of  disk  space  and  are  used  to  cluster  objects 
for  the  purpose  of  disk  storage  and  retrieval  efficiency.  Objects  that  are  expected  to  be  used  as  a  group 
by  applications  are  placed  in  the  same  segment  when  they  are  created,  using  the  SNEW  macro.’ 


*The  SNEW  macro  takes  a  segment  object  as  argument  and  creates  a  new  object  in  the  specified  segment 
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Current  Status  and  Futwe  Work 


The  GOOD  interface  was  implemented  fw  the  ObjectStore  and  has  been  used  to  implement 
IMPORT.  An  m^>lementation  for  die  OpenDB  has  begun.  The  OBST  system  is  a  candidate  as  well. 
Reviews  of  other  OODBMS  to  support  IMPORT  continue. 


4  FUTURE  WORK 


CoMcpt  Devd^nMt 

IMPORT  is  being  devel(^)ed  concurmitly  with  (Mher  plications  as  Persistrat  ModSim  and  ModLog 
are  being  fielded.  These  ai^lications  can  be  readily  ported  to  IMPORT,  so  that  they  will  be  invaluable 
in  testing  and  in  determining  needed  extensions.  As  the  product  enters  into  testing,  iwwly  revealed 
requirements  will  give  directimi  to  future  work. 

A  number  of  features  found  in  other  languages  suggest  avenues  for  research.  For  exairq>le,  the  class 
notion  might  be  extended  to  sport  static  fields  and  methods,  as  in  C-h-.  The  introduction  of  generics 
is  another.  An  inqrlementation  of  the  association  concept  frmn  OMT  has  some  precedence  in  research 
literature  (Rumbai^  1987),  and  would  permit  a  direct  mapping  from  OMT  style  design  into  code.  The 
concqjt  of  the  back-pointer  of  ObjectStore  is  a  limited  implementatitm  of  association.  Ejection 
capabUities  have  been  shown  to  be  quite  powerful  epcially  for  distributed  actor  conqiutational  iruxtels 
at^  for  constraint  programming  (Foote  1989). 

Note  that  the  current  implementation  is  a  **first-pa88”  and  must  be  reworiced  into  a  more  robust 
design.  The  SEE  classes  are  the  beginnings  of  a  frameworic  for  persistent  coiiq>ilation.  Fot  exanq)le,  the 
current  implementation  uses  the  union  structure  to  discriminate  ast  nodes.  This  is  not  an  object-oriented 
proach.  Mediods  for  each  language  construct  exist  in  the  current  idjsemantic.controller  class  and  its 
inverse,  the  id_code_generat(H'  class.  A  more  flexible  object-oriented  apoach  is  the  “Walker”  design 
pattern  (Gamma  1993).  In  this  pnxMch,  each  ast  node  has  a  ‘Traverse’”  method  that  takes  a  “Walker”’ 
object  as  an  argument  Each  ast  node  would  have  one  metlnxl  that  is  sent  to  a  walker  passing  the  node 
as  an  argument.  The  walker  is  then  repnsible  for  acting  on  the  node.  This  approach  keeps  the 
umteilying  representation  sirrqrle  and  collects  all  the  prations  on  it,  in  one  place.  Many  other  design 
patterns  could  be  equally  beneficially  when  plied  to  die  classes. 

A  major  piece  of  work  that  must  be  done  to  supirt  practical  applications  develoinnent  is  to 
construct  an  extensive  set  of  class  libraries.  The  INTERFACE  module  facility  and  the  availability  of  large 
bodies  of  existing  C  and  C++  code  should  make  this  task  easy  to  accomplish. 

The  current  simulation  runtime  is  a  sequential  model.  Also  being  evaluated  are  inqilementation 
strategies  fm*  parallel  runtimes,  such  as  Time  Warp  (Jefferson  1985).  Another  possible  approach  is  the 
extension  of  object  database  facilities  to  support  efficient  roll-back  mechanisms  using  fine-grain  versioning 
(Herring  1991).  The  general  area  of  Parallel  and  Distributed  Simulation  (PADS)  is  also  an  active  field 
of  research  that  offers  many  new  prroaches  (Steiiunan  1992).  Future  research  will  include  creating 
extensions  to  the  runtime  to  support  real-time  device  control,  as  discussed  in  Extensions,  p  51. 

Many  issues  relate  to  the  database-centered  plementadon  of  IMPORT.  The  use  of  the  object 
repository  has  opened  up  many  research  avenues  in  configuration  management  (Kalathil  1993).  Also,  the 
Common  Object  Request  Broker  Architecture  (0MB  1991)  combined  with  the  high  band  widA  sported 
t  he  Defense  Simulation  Internet  offers  an  approach  to  support  distributed  interactive  simulation  (Martin 
1992).  IMPORT  could  be  implemented  as  a  Umguage  server  with  programming  interfaces  (editors)  serving 
as  clients  in  a  heterogeneous  network  compilation  environment. 
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Integrated  Simulation  Language  Environment 

Tte  IMPORT/DOME  language  is  one  of  a  number  of  tools  that  comprise  the  Integrated  Simulation 
Language  Environment  (ISLE).  The  tools  in  the  ISLE  environment  all  interact  with  the  persistent  object 
repository.  The  object  repository  is  the  heart  of  the  enviroiunent,  and  stores  informiuion  ^XMit  the  class 
hierarchy,  the  programs  under  develofanent,  and  the  results  of  program  execution;  all  at  the  object-level 
of  granularity  (as  opposed  to  the  file,  or  function-level  gramilarities  that  exist  in  most  systems).  Figure 
20  shows  the  flow  of  information  between  components  of  ISLE. 

The  object  repository  (OR)  is  currently  realized  by  using  a  conunerciai  object-oriented  database. 
Already  defined  is  a  set  of  generic  access  primitives  (referred  to  as  Generic  Object-Oriented  Database,  or 
GOOD)  that  isolate  ISLE  from  dependence  upon  any  particular  database.  Currently,  the  generic  interface 
sufqwrts  ObjectStore  (Objectstore  1991),  and  ARPA’s  OpenDB  (Wells  1992).  The  Obst  object-oriented 
database  (Stone  1992)  is  being  evaluated  as  a  pt^ible  host. 

An  object  framework  of  classes  has  been  defined  that  model  the  intermediate  forms  of  the 
IMPORT/DOME  complation  structures.  These  classes  constitute  the  basic  data  structures  necessary  to 
support  the  software  engineering  environment.  They  permit  storage  in  the  object  repository  of  the 
IMTORT/DOME  programs,  and  provide  a  coitunon  access  mechanism  for  the  entire  ISLE  toolset. 

Storing  programs  at  the  object-level  of  granularity  allows  new  approaches  to  configuration 
management  and  version  control  by  allowing  a  finer  control  of  the  relationships  and  interdependencies 
between  objects  than  is  available  through  file-based  systems.  The  ISLE  Versionarian  maintains  a 
dependency  network  between  object  artifacts  in  the  object  repository  and  mediates  access  for  the  other 
ISLE  tools.  The  object  repository  organizes  versions  of  modules  into  compatible  configurations.  The 


Figure  20.  Components  of  the  ISLE  Architecture. 
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Versionarian  uses  both  infonnation  about  dependencies  between  software  objects  and  about  the  differences 
betweoi  veisicns  of  software  objects  to  automate  a  number  of  configuration  management  activities, 
including;  deteimining  if  a  certain  configuration  is  compatible,  generating  a  set  of  compatible  configura¬ 
tions  satisfying  certain  criteria,  and  deteimining  the  impact  of  proposed  changes  to  a  software  object  in 
a  omfiguration  (Kalathil  1993). 

A  Cranpilation  Manager  (CM)  assembles  an  executable  program  from  the  netwoik  of  objects  within 
a  configuratioiL  It  interacts  with  the  Versionarian  to  ensure  that  a  consistent  netwoik  of  source  objects 
are  selected.  It  is  also  le^nsible  for  optimizing  the  virtual  methods  to  eliminate  the  overhead  associated 
with  function-table  lookup  when  the  methods  are  not  overloaded.  The  Compilation  Manager  can  use  the 
cafnbilities  of  ftie  Versionarian  that  maintain  dependency  infonnation  at  object-level  granularity  to  facili¬ 
tate  die  implementaticm  of  smart  rectunpilation  algorithms  (Tichy  1986). 

Many  of  the  tools,  e.g.,  the  Interpreter,  Debugger,  and  Profiler,  depend  on  the  Compilation  Manager. 
The  interpreter  provides  an  interactive  environment  for  exploratory  (or  bottom-up)  programming.  The 
Debugger  helps  identify  and  correct  programming  problems.  The  Profiler  helps  create  efficient  programs 
by  alerting  the  user  to  the  most  computationally  intensive  methods.  All  of  these  tools  interact  with  the 
object  repository  (through  the  CM  and  Versionarian)  and  operate  fiom  the  intermediate  form  of  IMPORT/ 
DOME  iHograms. 

The  remaining  tools  work  to  convert  source  input  into  the  intermediate  representation,  and  currently 
consist  of  the  IMPORT/DOME  parser,  the  unpaiser,  editor,  and  librarian.  The  parser  takes  object 
specifications  as  input  and,  working  in  conjunction  with  the  Versionarian,  places  inteimediate-form  objects 
into  the  objea  rqiositoty  (Hgure  20).  The  unparser  retrieves  intermediate-fonn  objects  and  translates 
them  bade  into  source  for  the  editor.  The  editor  understands  the  syntax  of  the  language,  and  supports  the 
direct  manipulation  and  editing  of  these  intermediate-fonn  objects.  Finally,  the  librarian  is  a  know- 
ledge-based  programming  assistant  that  helps  foe  user  to  navigate  foe  class  hierarchy  and  find  ai^licable 
objea  definitions. 


58 


5  SUMMARY 


This  work  has  described  IMPORT/DOME,  a  new  language  system  designed  and  implemrated  to 
provide  full  integration  of  previously  developed  software  technologies  to  support  general  modeling  and 
simulation.  IMPORT  is  an  integrated  application  of  an  object-oriented,  inqierative  and  declarative  pro- 
graimning  language  that  combines  process-based  discrete-event  simulation  and  persistent  object  storage 
to  address  large-scale,  conqrlex  systems  modeling. 

IMPORT  is  characterized  by  the  following: 

•  It  introduces  two  new  module  types:  the  KNOWLEDGE  and  the  INTERFACE  modules. 

•  Records,  procedures,  pointers,  and  subrange  types  have  been  removed  from  IMPORT. 

•  IMPORT  is  a  strongly  typed  language,  and  variables,  constants,  classes,  and  methods  must  be 
declared  before  being  used. 

•  Method  bodies  are  the  only  places  where  inqjerative  or  declarative  code  can  be  found. 

•  IMPORT  uses  dynamic  memory  numagement — built-in  procedures  for  the  creation  of  object 
instances. 

•  IMPORT  inherits,  and  augments,  the  built-in  procedures  and  fimctions  of  ModSim. 

•  At  present,  IMPORT  depends  of  Standard  Libraries  for  simulation  sui^rt  and  persistence. 

•  IMPORT  is  a  fully  functional  programming  language  with  an  iiiq>lementation  based  on  an 
object-oriented  database. 

The  current  implementation  of  IMPORT  is  a  “first  pass,”  being  further  developed  as  other  ai^lica- 
tions  are  being  fielded.  As  product  is  being  tested  and  validated,  new  avenues  for  research  and  product 
improvement  are  being  defined  and  explored. 
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Appendix  A 

IMPORT  Context  Free 
Grammar 


This  appendix  contains  the  context  free  grammar  for  Import.  The  syntax 
is  represented  in  the  concise  Bachus-Naur  Form.  No  semantics  are  attached 
to  the  symbols.  The  following  regular  expression  operators  are  used  as  a 
notational  convenience. 

An  asterisk  (*)  denotes  0  or  more  symbols. 

A  plus  (+)  denotes  1  or  more  symbols. 

A  question  mark  (?)  denotes  0  or  1  symbols. 


Terminal  symbols  (reserved  words)  are  shown  in  all  capital  letters  here. 
However,  the  current  IMPORT  implementation  is  case  insensitive  to  reserved 
words.  Identifiers  cannot  be  reserved  words.  The  start  symbol  is  program. 


A.l  Module  Definitions  and  Import  Statement 

program  — *  (definition.module 

I  implementation.module 
I  interface-module 

I  k«y)+ 

definition-module  — *  OEFiNITION  MODULE  identifier  semi 

(import  jrtatement)* 
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(const.dcci  I  typc.decl  |  obj.type_<fecl)* 

END  MODULE  period 

implement»t»on_module — »  IMPLEMEHTATIOM  MODULE  identifier  semi 

(import^atement)* 

(obj.methods_deci)* 

END  MODULE  period 


interface.module 

— »  INTERFACE  MODULE  identifier  semi 
(ext_obj-metliods-decl)* 

END  MODULE  period 

key 

— ►  KEY  identifier  colon 

FROM  identifier  CREATE  identifier 

INVOKE  identifier  args  period 

importjstatement 

— »  FROM  identifier  IMPORT  (importJtemJist)+  semi 

importJtemJist 

— ►  import  Jtem|  import  Jtem  comma  importJtemJist 

import  Jtem 

— ►  (ALL)?  identifier  (asJtem)? 

as.item 

— »  AS  identifier  (l^aren  enumJtemJist  r-paren)? 

enumJtemJist 

— ►  identifier  (AS  identifier)? 

1  identifier  (AS  identifier)?  comma  enumJtemJist 

A.2  Constant  Declarations 

const.deci 

—  CONST  constJdJist 

const.idJist 

— »  const_id  const.id_list 

1  « 

const.id 

— >  identifier  eqi  expression  semi 
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A.3  Type  Declaration 


type.decl  — »  TYPE  typcJdJist 

typcJdJist  — »  typc->d  type-idJist 

I  objjtyp«-decl  typeJdJist 

I  « 

typ«-id  — »  identifier  eql  type  semi 

type  — ►  identifier 

I  enumjtype 
I  INTEGER 
I  REAL 
I  BOOLEAN 
I  STRING 
I  CHAR 
I  LIST 
I  ADDRESS 

I  ARRAY  l^acket  integer  rjbracket  OF  type 


enum-type  — *  l^aren  enum-typeJist  r-paren 

enum.typeJist  — *  identifier 

I  identifier  comma  enum-typeJist 


A.4  Variable  Declaration 

var.jfecl  — ►  VAR  varJdJist 
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varJdJist 

— »  var  Jd  semi  var  Jd  Jist 

1  « 

v*rjd 

— »  identifier  (comma  identifier)*  colon  type 

A.5  Object  Definitions 

obj-type.decl 

— *  identifier  eql  OBJECT  (super.classes)?  semi 
obj.type-body 

END  OBJECT  semi 

1  identifier  eql  OBJECT  semi  EXTERNAL  semi 
ext.obj.typeJ>ody 

END  OBJECT  semi 

1  identifier  eql  OBJECT  semi  FORWARD  semi 

super.classes 

— >  i.paren  super.classJist  r.paren 

super.classJist 

— ►  identifier 

1  identifier  comma  super.classJist 

obj-type-body 

— *  field.methodJist 
(privateJist)? 

(overrideJist)? 

fieidjnethodJist 

- »  € 

1  var  Jd  semi  field  jnethodJist 

1  method.prototype  semi  field jnethodJist 

privateJist 

— *■  PRIVATE  field jnethod Jist 
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overrideJist  — »  OVERRIDE  field-methodJist 

mcthod^HTototype  — »  ask.fneth-proto 

I  tell.fncth^oto 
I  query_nneth4)roto 
I  op.fneth^oto 
I  cofist.metli^oto 
I  dest-meth^oto 


ask_meth-proto  — »  ASK  METHOD  identifier 

parameters 

(return-type)? 

tell-meth-proto  — »  TELL  METHOD  identifier 

parameters 

query-meth-proto  — ►  QUERY  METHOD  identifier 

parameters 
colon  BOOLEAN 

op-meth-proto  — ►  OPERATOR  METHOD  operator 

parameters 

(return.type)? 

const-meth-proto  — »  CONSTRUCTOR  METHOD  Objinit 

paran>eters 

dest.meth-proto  — ►  DESTRUCTOR  METHOD  ObjTerminate  l.paren  r-paren 

parameters  — ►  l-paren  (parameterJist)?  r_paren 

parameterJist  — »  formal^arameter 

I  formal-parameter  semi  parameterJist 

formal-parameter  — »  IN  varJd 

I  OUT  varJd 
I  INOUT  varJd 
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rcturn.type 


colon  type 


operator  — » times  |  divide  |  plus  |  minus  |  eql 

I  n«l  I  I  f«r  I  f«q  I  “Wf n 

I  pluseql  I  minuseql  |  timeseql  |  diveql 


A.6  Object  Declaration 

A.6.1  Object  Declaration  in  Implementation  Modules 

obj-methods.decl  — »  OBJECT  identifier  semi  (method.decl)* 

END  OBJECT  semi 

method.decl  — »  method.prototype  semi  (varjdeci  |  const.decl)* 

statementJalock  METHOD  semi 


A.6.2  Object  Declaration  in  Interface  Modules 

ext.obj.methods.deci  — »  OBJECT  identifier  (AS  identifier)?  (IN  language)?  semi 

(ext jfield.rename  |  ext  jneth.proto)* 

END  OBJECT  semi 

language  — ►  C+4- 

I  c 

ext.obj.typeJ>ody  — *  varJd  semi  ext-Eeidjnethod.iist 

I  extjdef  jneth.proto  semi  ext  Jield.method  Jist - 

ext.fieidj'ename  — *  identifier  (AS  identifier)?  semi 
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txt.dcfjneth4>roto  —*  askjmcth.proto 
I  op-mcth^iroto 
I  cofist_nMth^oto 
I  dest.jneth^oto 

ext-meth-proto  — »  ext^Mkjrwth^oto 

I  cxtjopjncth4>roto 
I  «xtjconst.meth.proto 
I  cxt^deft-ineth^oto 

cxt-ask_meth^roto  — »  ASK  METHOD  identifier 

(AS  identifier)?  semi  (STATIC  semi)? 

ext.op^eth^roto  — »  OPERATOR  METHOD  operator 

(AS  operator)?  semi  (STATIC  semi)? 

ext.const-meth_proto  — *  CONSTRUCTOR  METHOD  Objlnit 

(AS  identifier)?  semi  (STATIC  semi)? 

ext.dest.meth^roto  — ^  DESTRUCTOR  METHOD  ObjTerminate 

(AS  identifier)?  semi  (STATIC  semi)? 


A.7  Expressions 

assignment  — *  location  assign  expression 

I  location  pluseql  expression 

I  location  minuseql  expression 

I  location  timeseql  expression 

I  location  diveql  expression 

expression  — >  integer 

I  real 

I  string 


A7 


bcation 


char 

list 

location 

NULL 

UNINSTANTIATED 

minus  expression  %prec  ominus 
expression  minus  expression 
expression  plus  expression 
expression  times  expression 
expression  divide  expression 
expression  DIV  expression 
expression  MOO  expression 
l^aren  expression  r-paren 

boolval 

NOT  expression 
expression  AND  expression 
expression  OR  expression 

expression  eql  expression 
expression  neq  expression 
expression  Iss  expression 
expression  leq  expression 
expression  gtr  expression 
expression  geq  expression 

askjnethodJnvocation 
telIjnethodJnvocation 
operator  jnethodJnvocatbn 
query  .met  hodJnvocation 
builtJn_func 


— »  (inheritedJnherited-from)?  identifier 
I  SELF 

I  location  IJ>raclcet  expression  rJbracket 
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boolval  — »  TRUE 

I  FALSE 


list  — ¥  IJiracket  expression  (comma  expression)*  r.bracket 


A.8  Method  Invocations 

inherited-from  — »  FROM  identifier 

inherited.inherited.from  — »  INHERITED  FROM  identifier 

methodJnvocation  — *  askjnethodJnvocation 

I  telljnethodJnvocation 
I  query.method.invocation 


askjnethodJnvocation  — *  ASK  expression  (TO)?  identifier 

args  (inherited  Jrom)? 

tell.methodJnvocation  — ►  TELL  expression  (TO)?  identifier 

args  (inherited  Jrom)? 

queryjnethodJnvocation  — »  QUERY  identifier  (ABOUT)?  identifier 

args  (inherited  Jrom)? 

args  — » l.paren  (argJist)?  r.paren 

argJist  — ¥  (expression  comma)*  expression 


A.9  Built-In  Functions 


buiKJnjfunc 


abs 

cap 

chartostr 

chr 

float 

inttostr 

loiwer 


max 

maxof 

min 

minof 

odd 

ord 

persistent 

position 

realtostr 

round 

schar 

simtime 

strcat 

strlen 

strput 

strtoint 

strtoreal 

substr 

trunc 


— *  abs|  cap|  chartostr|  chr|  float|  inttostr|  loiwer 
I  max|  maxof]  min)  minof)  odd)  ordj  persistent]  position 
I  reaKostrj  round)  schar)  strcat)  strlen)  strput)  strtoint 
)  strtoreal)  substr)  trunc)  upper)  val 
)  simtime 

— »  ABS  l^aren  expression  r.4>aren 
— »  CAP  l.paren  expression  r^aren 
— *  CHARTOSTR  i.paren  expression  r4>aren 
— >  CHR  l_paren  expression  r-paren 
— *  FLOAT  l.paren  expression  r_paren 
— »  INTTOSTR  l.paren  expression  r^aren 
— »  LOWER  l..paren  expression  r^aren 


— »  MAX  l^iaren  scalar  Jype  r4>aren 
— »  MAXOF  l4Miren  argJist  r4>aren 
— »  MIN  l.4>«’en  scalarJype  r_paren 
— *  MINOF  l.paren  argJist  r-paren 

— »  ODD  l^aren  expression  r^aren 
— *■  ORD  l^ren  expression  r4>aren 
— *  PERSISTENT  l.paren  expression  r^aren 
— *  POSITION  l.^en  expression  comma  expression  r_paren 
— *  REALTOSTR  l^aren  «pression  r-paren 
— *  ROUND  i.p«en  expression  r-paren 
— »  SCHAR  l-paren  expression  comma  expression  r-paren 
— »  SIMTIME  l^ren  r-paren 
— *  STRCAT  l.4»aren  argJist  r^aren 
— *  STRLEN  l-paren  expression  r-paren 
— *  STRPUT  i.paren  argJist  r^aren 
— *  STRTOINT  i^aren  expression  r-paren 
— >  STRTOREAL  l-paren  expr^sion  r-paren 
— *  SUBSTR  l-paren  expression  comma  expression  comma 
expression  r^aren 

— »  TRUNC  l^aren  expression  r-paren 


AlO 


upper 

vei 


scaiar.type 


A.IO  Built 

builtJn^oc 


abort 

dec 

dispose 

halt 

inc 

input 

insert 

new 

output 

replace 

strtochar 

interrupt 

interrupt_aii 


— »  UPPER  Lparen  expression  r_paren 
— »  VAL  i.paren  scalarJype  comma  expression  r^aren 
I  VAL  lparen  identifier  comma  expression  r.paren 

— »  INTEGER 
I  REAL 
I  CHAR 
I  BOOLEAN 


in  Procedures 


— *■  abort  I  dec|  lialt|  disposal  inc|  input|  insert 
I  new|  output!  repiscci  strtochar 
I  interrupt)  interrupt-all 

— *  ABORT 

— *  DEC  l.paren  expression  r4>aren 
I  DEC  l.paren  expression  comma  expression  r^aren 
— »  DISPOSE  l^>aren  expression  r-paren 
HALT 

— »  INC  l4>aren  expression  r-paren 
I  INC  l.paren  expression  comma  expression  r-paren 
— *  INPUT  l^taren  (argJist)?  r^^aren 
— *  INSERT  l-paren  expression  comma  expression  comma 
expression  r^ren 

— »  NEW  l-paren  location  (comma  expression)?  r_paren  args 
— ►  OUTPUT  lparen  (argJist)?  r-paren 
— *  REPLACE  l.paren  expression  comma  expression  comma 
expression  comma  expression  r.paren 
— »  STRTOCHAR  l-paren  expression  comma  expression  r-paren 
— »  INTERRUPT  l-paren  expression  comma  expression  r.paren 
— >  INTERRUPTALL  l-paren  expression  coma  expression  r.paren 
I  INTERRUPTALL  l.paren  expression  r-paren 


All 


A.  11  Statements 


stattmcnt 


statcmentJist 

bioclc_statemcnt 

statemcnt.bbck 

if^atcment 

eisifJist 


— *  anigfimant 
I  mcthodJnvocation 
I  buiKJn^oc 
I  block.ttatefncnt 
I  ifjitatcment 
I  cafajttatatnant 
I  «vhile.jtatafnent 
I  rcpaatjitatefnant 
I  for.^tafncfit 
I  loop-statamant 
I  axitjrtatafnant 
I  raturnjrtatamaiit 
I  tarminatajitatamant 
I  wrait^atamant 
I  traiuactionjitatamant 
I  abort^atamant 

— »  statamant  satni  statamant  Jist 

I  « 


— »  BLOCK  (const.dacl|  typa.dacl)*  statafnant.block  BLOCK 

— *•  BEGIN  statamant-list  END  sami 

— *  IF  axprassion  ttatatnant_list 
(abifJist)? 

(aba^auaa)? 

END  IF 

— »  alsif_clausa 
I  aUif  jclausa  alsif  Jist 
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tlsif_daiiM 

eUe.clause 

case_statement 

when.list 

when.dause 

otherwise-dause 

caseJabel 

while_statem«fit 

rapeat^atement 

for^atement 

by.dause 

loopjrtatemcnt 

exitotatement 

returnjdatemcnt 


— »  ELSIF  axprasnon  statamcntJist 

— »  ELSE  statamcntJist 

— »  CASE  expression  whenJist  (otherwise-dause)?  END  CASE 

— »  when.dause 
I  when-dause  whan  Jist 

— *  WHEN  caseJabd  colon  statementJist 

— »  OTHERWISE  statementJist 

— ►  integer 
I  boolval 
j  char 

— *  WHILE  expression  statementJist  END  WHILE 

— »  REPEAT  statementJist  UNTIL  expression 

— *  FOR  location  assign  expression  TO  expression 
(byjdausc)?  statementJist  END  FOR 
I  FOR  location  assi^  expression  DOWNTO  expression 
(byjdause)?  statement.list  END  FOR 

— >  BY  expression 

LOOP  statementJist  END  LOOP 
—  EXIT 

— ►  RETURN  (expression)? 
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tcrmiiMtcjrtatcfncnt 


TERMINATE 


wait^atcmcnt  — »  WAIT  DURATION  expression  statementJist 

(interrupt.daitte)?  END  WAIT 

I  WAIT  FOR  expression  TO  identifier  args  (inlwited.from)? 

statement-list  (interrupt-dause)?  END  WAIT 
I  WAIT  FOR  TRIGGER  expression 

interrupt-clause  — *  ON  INTERRUPT  statement-list 

transaction-statement — »  T»<ANSACTION  statement.list  (abort-clause)? 

END  TRANSACTION 

abort-clause  — »  ON  ABORT  statementJist 

abort-statement  — »  ABORT 

I  ABORT  ALL 


A.12  Query  Statement 


query-statement 


qucry4(oailist 


query-goal  period 
(IF)?  ouery-goaliist 
THEN  query-goal  period 


query-goallist  query-Connector  query^(oal 
query^oal 


query-goal  — *  identifier 

I  identifier  l.paren  query-goallist  r-paren 

I  identifier  asdgn  query jnmplexpr 

I  integer 
I  real 
I  char 
I  string 

IJbracket  rJbracfcet 


4 
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I  qucry_consiist 


qiicry.consiist  — » IJtracket  query.coiiscxpHist  r J>rad(et 

I  l^acket  qucry.consexpritst  '  identifier  racket 

query.consexprlist  — »  qiiery_conacxprtist  comma  qiieiry_conse)(pr 
I  query.consttcpr 

query-consexpr  — »  query4(oai 

query-simexprlist  — *■  qncry-simexpHist  query-connector  query-simplexpr 
I  queryjiimpiexpr 

qucry-simplexpr  — »  query-term  query.addop  query-term 

I  query-term 

query-addop  — »  plus 

I  minus 

query-term  — *  query.factor  query .mubp  query-factor 

I  queryJactor 

query-mulop  — » times 

I  divide 

I  " 

I  ’ 

query-factor  — » integer 

I  real 
I  identifier 

I  l-paren  query-simplexpr  r.paren 
I  identifier  l-parcn  query-simexpriist  r4>aren 

query-connector  — »  AND 

I  comma 
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A.13  Comments 


comment  — ►  nested-comment 

I  singleJine-comment 

nested-comment  — »  (  l_bracc  ncsted-comment  rJtrace  )+ 
singleJine-comment-^  minus  minus  (any_character)* 


A.  14  Operator  Symbols 

times 
divide 
plus 
minus 
eql 
neq 
iss 
leq 

geq 

assign 
pluseql 
minuseql 
timeseql 
diveql 


A.15  Punctuation 

All  symbols  on  the  right  hand  side  are  terminab. 

I.paren 
r-paren 
semi 
colon 
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comma  — »  , 

Lbracket  — ^  [ 

rJbracket  — ►  ] 

l-brace  — »  { 

r  JMracc  — ►  } 

period  — ►  . 
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Appendix  B 

IMPORT  Database  Class 
Library 


Support  for  persistent  object  storage  in  Import  is  provided  through  a  li¬ 
brary  of  pseudo  classes.  These  classes  were  first  prototyped  in  the  Persis¬ 
tent  ModSim  development  effort  [13].  They  were  further  refined  in  the 
Generic  Object  Oriented  Database  (Good)  interface  developed  for  imple¬ 
menting  Import  described  in  Appendix  ??.  These  Import  pseudo  classes 
are  implemented  through  use  of  the  Good  interface.  Hence,  persistence  in 
the  Import  language  is  supported  through  the  same  underlying  mechanizm 
as  is  its  implementation.  Porting  the  Good  to  other  database  hosts  ports 
the  langauge  manipulation  facilities  (parser,  code  generator,  etc.)  as  weU  as 
the  language’s  ability  to  manipulate  persistent  storage. 

B.l  Overview 

It  became  apparent  in  the  development  of  Persistent  ModSim  that  it 
is  necessary  for  programmers  to  know  and  understand  the  consequences 
of  object  persistence.  This  capability  dramatically  changes  the  manner  in 
which  progrants  are  designed  and  implemented.  Therefore  it  was  decided 
that  more  access  to  the  underlying  database  functionality  was  required  and 
that  it  be  presented  to  programmers  in  a  consistent  manner.  We  chose  to 
provide  the  interface  to  persistent  storage  in  PERSISTENT  ModSim  through 
use  of  a  database  class  library.  This  same  approach  is  taken  in  Import. 

Through  the  database  class  library  the  essential  features  of  database 
functionality  are  presented  as  objects  to  the  user.  This  approach  is  widely 
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used  and  pennits  control  over  how  much  detail  of  the  underlying  database 
model  is  revealed.  The  class  librsiry  represents  a  simplified  model  of  object 
database.  This  is  consistent  with  the  object  paradigm  of  adding  extended 
features  through  classes  that  can  be  inherited  from.  It  permits  programmers 
the  flexibility  to  develop  further  specializations  based  on  this  model  for  spe¬ 
cific  purposes.  A  consequence  of  this  approach  is  the  necessity  to  introduce 
two  new  concepts  into  the  language  in  the  form  of  extended  syntax.  These 
two  extensions  are  concerned  with  the  specification  of  persistent  allocation 
of  objects  (the  overloaded  NEW)  amd  transaction  management  (the  TRANS¬ 
ACTION  statment)  to  permit  concurrent  access  to  databases  by  multiple 
users. 

This  appendix  provides  documentation  of  the  database  model  of  Impost. 
The  model  consists  of  a  set  of  classes  representing  database  functionality 
to  the  programmer.  The  database  class  library  consists  of  the  following 
classes:  Database,  Directory,  Segment,  Collection,  Cursor,  Configuration, 
and  Workspace.  Each  class  is  implemented  as  in  separate  DEFINITION  file 
which  can  be  imported  into  any  Import  program.  These  classes  have  no 
restrictions  on  them,  they  can  be  inherited  from  and  their  methods  overrid¬ 
den  as  necessary.  However,  there  are  no  corresponding  IMPLEMENTATION 
files.  The  code  implementing  these  classes  is  contained  in  the  Good. 


B.2  Databases 

Import  variables  of  the  object  type  (class)  Database  represent  databases. 
Databases  can  be  thought  of  as  files  that  store  objects.  In  an  Import 
program,  an  instance  of  a  Database  object  is  associated  with  one  physical 
database  at  any  ^ven  time.  Database  objects  have  no  fields-only  methods. 
These  methods  implement  the  basis  notions  associated  with  database  op¬ 
erations.  The  methods  of  database  objects  include  create,  open,  close,  and 
delete.  There  are  methods  for  determining  the  status  of  the  database  as 
well  as  methods  associated  ^th  the  functioning  of  the  other  classes  in  the 
database  library. 

The  class  database  allows  programs  to  create  and  manipulate  persistent 
objects.  Instances  of  this  class  are  used  a  parameters  in  calls  to  NEW  to 
specify  were  new  persistent  objects  will  be  allocated.  An  open  count  is 
maintained  for  each  datsd)a8e  and  represents  the  number  of  times  it’s  Open 
method  was  called  during  the  current  process.  When  the  open  coimt  is  set 
to  0  the  database  is  closed.  All  databases  are  automatically  closed  when  the 
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program  terminates.  Object  instances  of  this  class  need  not  be  persistent 
themselves.  The  definition  module  for  the  Database  class  is  show  below. 
FoUowing  is  a  description  of  the  methods  of  this  class. 

DEFIIIITION  MODULE  Database; 


FROM  DatabaseRoot  IMPORT  DatabaseRoot ; 

FROM  Segment  IMPORT  Segment; 

TYPE 

Database  ■ 

OBJECT 

ASK  METHOD  AllosEzternalPointersO ; 

ASK  METHOD  RoorDirO:  Directory; 

ASK  METHOD  Create(IH  pathname  :  ARRAY  OF  CHAR; 

II  mode  :  IITEGER; 

II  if.ezlsts.overwrite  :  BOOLEAI); 

ASK  METHOD  DestroyO; 

ASK  METHOD  Open(II  readonly  :  BOOLEAI) ; 

ASK  METHOD  openCll  pathname  :  ARRAY  OF  CHAR; 

II  readonly  :  IITEGER)  :  Database; 

ASK  METHOD  CloseO; 

ASK  METHOD  GetPathlame(OUT  pathlame  :  ARRAY  OF  CHAR) ; 

ASK  METHOD  LookupCil  pathname  :  ARRAY  OF  CHAR; 

II  createMode  :  IITEGER)  :  Database; 

ASK  METHOD  Of (II  item  :  REFEREICE)  :  Database; 

ASK  METHOD  IsOpenC):  BOOLEU; 

ASK  METHOD  IsHritableO :  BOOLEAI; 

ASK  METHOD  IsEqualToCll  dbl  :  Database; 

11  db2  r  Database)  :  BOOLEAI; 

ASK  METHOD  CreateSegmentO  :  Segment; 

EID  OBJECT; 

EID  MODULE 

AllowExtemalPointers:  Allow  database  pointers  to  cross  databases  bound¬ 
aries.  After  perfoming  this  operation  on  a  database,  the  current  process  and 
subsequent  processes  can  store  cross-database  pointers  there.  When  you  ac¬ 
cess  a  cross-database  pointer,  if  the  database  it  points  to  is  not  open,  it  will 
be  opened  automatically. 
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Close:  Decrements  the  open  count  of  the  database.  If  the  open  count  is  0 
the  database  is  closed.  If  the  open  count  is  greater  than  0  the  database  access 
(read  or  read/ write)  is  returned  to  the  previous  access  mode.  If  this  method 
is  caDed  from  within  a  transaction,  the  open  count  is  not  decremented  until 
the  end  of  the  current  outermost  transaction. 

Create:  Creates  a  new  database  with  the  specified  pathname  and  mode. 
The  values  for  mode  are  the  same  as  used  in  the  Unix  chmod  command. 
If  the  parameter  if.exists.overwrite  is  set  to  true  a  new  database  will  be 
created  even  if  one  by  that  name  already  exists,  otherwise  a  runtime  error 
will  occur.  A  root  directory  of  this  database  is  automatically  created  if  this 
operation  succeeds. 

CreateSegment:  Creates  a  segment  in  the  database  and  returns  an  object 
of  type  Segment. 

Destroy:  Deletes  the  database.  This  method  must  be  called  within  a 
transaction. 

GetPathName:  Returns  the  pathname  of  the  database.  This  pathname 
will  always  begin  with  a  ”/”. 

IsEaualTo:  Returns  true  if  dbi  and  db2  are  the  same  database. 

IsOpen:  Returns  true  if  the  database  is  open,  otherwise  returns  false. 

IsWritable:  ketums  true  if  the  database  is  writable  by  the  current  pro¬ 
cess.  Returns  false  if  the  database  has  been  opened  for  read-only  or  if  the 
process  does  not  have  write  permission. 

LookUp:  Associates  the  database  specified  in  pathname  with  an  instance 
of  the  class  Database.  If  the  database  is  not  found  a  runtime  error  will  occur 
unless  createMode  is  non-zero.  If  createMode  is  non-zero  and  the  database 
was  not  found  a  new  database  will  be  created.  Note  this  method  does  not 
open  the  database. 

Ofr^phis  method  takes  a  variable  of  type  object  and  returns  the  database 
object  it  is  stored  in. 

Open:  Opens  the  database  associated  with  the  object.  If  readOnly  is 
non-zero  the  database  is  opened  for  read  access  only,  otherwise  it  is  open 
for  read/write. 

RootDir:  A  pointer  points  to  the  root  directory  of  this  database  is  re¬ 
turned  which  can  be  used  for  subsequent  directory  maninulation. 
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B.3  Directories 


The  Directory  class  provides  for  stracturing  entry  points  into  databases. 

The  named  objects  in  a  database  are  organized  in  an  Unix-like  directory 
hierarchy.  A  directory  may  contain  other  directories  and  named  objects. 

The  default  working  directory  is  the  root  directory  (**/’*)  which  is  created 
automatically  whenever  a  new  database  is  created.  Fkom  there,  other  named 
obj^ts  and  directory  objects  can  be  manipulated  through  directory  class 
methods.  The  methods  of  directory  objects  include  Mkdir,  Rmdir,  Getdir, 
Lookup,  Insert,  Remove  and  Ls.  Path  names  to  named  objects  or  directory 
objects  are  specified  either  relative  to  the  current  working  directory  or  by 
using  the  complete  path  name  starting  with  the  root  (“/”). 

DEFIMITION  NODULE  Directory: 

TYPE 

Directory  ■ 

OBJECT 

ASK  METHOD  Lookup  (IK  db  :  Databaee; 

II  pathnaae  :  ARRAY  OF  CHAR)  :  REFERENCE; 
ASK  METHOD  Insert  (IN  dimaae  :  ARRAY  OF  CHAR; 

II  itea  :  REFERENCE; 

IN  naae  :  ARRAY  OF  CHAR) ; 

ASK  METHOD  Lookup  (II  objnaae  :  ARRAY  OF  CHAR)  :  REFERENCE; 
ASK  METHOD  Insert  (IN  itea  :  REFERENCE; 

IN  objnaae  :  ARRAY  OF  CHAR)  :  BOOLEAN; 

ASK  METHOD  Reaove  (IN  objnaae  :  ARRAY  OF  CHAR)  :  BOOLEAN; 

ASK  METHOD  Mkdir  (IN  dimaae  :  ARRAY  OF  CHAR)  :  Directory; 

ASK  METHOD  GetDir  (IN  db  :  Database; 

IN  dimaae  :  ARRAY  OF  CHAR)  :  Directory; 

ASK  METHOD  Radir  (IN  dimaae  :  ARRAY  OF  CHAR)  :  BOOLEAN; 

ASK  METHOD  Ls  (); 

END  OBJECT; 

END  MODULE. 

Getdir:  Gets  a  directory  object  with  its  entry  name  “dir-name”  in  the 
specified  database.  Returns  a  pointer  to  the  directory  if  found,  else  returns 
a  NULL  pointer. 
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Insert:  Inserts  the  object  pointed  to  by  "item”  into  the  directory  "dir”, 
with  the  name  "name”. 

Lookup:  Looks  up  a  named  object,  which  can  be  either  an  ordinary 
object  or  a  directory  object,  in  the  database.  A  pointer  to  the  object  is 
returned. 

Ls:  Returns  a  list  containing  the  names  of  the  named  objects  and  sub¬ 
directories  in  this  directory. 

Mkdir:  Makes  a  new  subdirectory  ‘^dir.name’’  in  this  directory,  and  re¬ 
turns  a  pointer  to  this  new  subdirectory. 

Remove:  Removes  an  entry  for  a  named  object  “objjDame”  from  this 
directory.  Does  not  delete  the  object  from  the  database.  Returns  1  if  the 
object  has  been  removed  successfully,  else  0. 

Rmdir:  Removes  an  entry  for  a  named  subdirectory  "dir-name”  from 
this  directory.  Does  not  delete  the  subdirectory  from  the  database.  Returns 
1  if  the  subdirectory  has  been  removed  successfuUy,  dse  0. 

B.4  Collections  and  Cursors 

The  Collection  module  provides  classes  for  grouping  objects  together  and 
accessing  them.  The  objects  contained  in  these  collections  are  refered  to  as 
elements.  The  foUowing  classes  are  found  in  the  Collection  module:  List, 
ParseList,  Set,  and  TVee.  Instances  of  these  classes  may  be  allocated  in  a 
Database,  a  Segment,  or  a  Configuration.  They  have  methods  to  insert  and 
remove  objects  and  for  comparing  various  prop^ies  such  as  equal  to  and 
greater  than. 

The  cursor  classes  provide  for  iteration  over  the  elements  of  the  collection 
classes.  There  is  a  cursor  class  associated  with  each  of  the  collection  classes. 
An  instance  of  a  cursor  object  created  for  a  pven  instance  of  a  collection 
object.  The  cursor  object  has  methods  to  return  specific  members  of  the 
given  collection  object.  Some  of  the  cursor  object’s  methods  are  first,  last, 
next,  etc.  The  cursor  object  also  has  methods  to  insert  objects  into  its 
collection.  Any  number  of  cursor  objects  can  be  instanciated  for  a  given 
coUection  object.  Cursor  objects  are  most  often  allocated  transiently. 


DEFINITIOH  MODULE  Collection; 
FROM  Database  IMPORT  Database; 

TYPE 
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List  ■ 

OBJECT 

ASK  METHOD  CrsatsInO&tsbsssdl  db  :  Oatabass) ; 
ASK  METHOD  IsEaptyO:  BOOLEAI; 

ASK  METHOD  Inssrt(II  alas  :  REFEREMCE); 

ASK  METHOD  InsartFirstCll  alaa  :  REFEREMCE); 
ASK  METHOD  Raw>va(II  alas  :  REFEREMCE) ; 

ASK  METHOD  RaMvaFlrstO ; 

ASK  METHOD  RasovaLastO ; 

ASK  METHOD  SizaO  :  IMTEGER; 

END  OBJECT: 

ListCursor  * 

OBJECT 

ASK  METHOD  Craata(IH  list:  List); 

ASK  METHOD  FirstO:  REFEREMCE; 

ASK  METHOD  InsartAftarClM  raf:  REFEREMCE): 

ASK  METHOD  InsartBaforaClM  raf:  REFEREMCE); 

ASK  METHOD  IsMulK):  BOOLEAM; 

ASK  METHOD  Last():  REFEREMCE; 

ASK  METHOD  Mora():  BOOLEAM; 

ASK  METHOD  Hazt():  REFEREMCE; 

ASK  METHOD  PraviousC):  REFEREMCE; 

ASK  METHOD  RmovaAtO; 

ASK  METHOD  RatziavaO:  REFEREMCE; 

END  OBJECT; 

ParsaList  • 

OBJECT 

ASK  METHOD  Appand  (IB  list  :  ParsaList); 

ASK  METHOD  CrsataInDatabasa(IH  db  :  Databasa); 
ASK  METHOD  IsEstptyC):  BOOLEAM; 

ASK  METHOD  Insart(IH  alas  :  REFEREMCE); 

ASK  METHOD  InsartFirst(IH  alas  :  REFEREMCE) ; 
ASK  METHOD  RarcradM  alas  :  REFEREMCE); 

ASK  METHOD  RasovaFirstO ; 

ASK  METHOD  RaaovaLastO ; 

END  OBJECT; 
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Purs«LlstCur>or  ■ 

OBJECT 

ASK  METHOD  CrMt«(II  parsAList:  ParsaList); 
ASK  METHOD  FlrstC):  REFEREHCE; 

ASK  METHOD  InaartAftarCll  raf:  HEFEREICE); 

ASK  METHOD  IslulK):  BOOLEAI; 

ASK  METHOD  MoraO:  BOOLEAI; 

ASK  METHOD  laxt():  REFEBEHCE; 

ASK  METHOD  RaMTaAtO; 

ASK  METHOD  RatriavaO:  REFEREICE; 

ASK  METHOD  TalK):  ParaaList; 

EHD  OBJECT; 

Sat  ■ 

OBJECT 

ASK  METHOD  CraatalnDatabasaCll  db  :  Databasa); 
ASK  METHOD  IsBq>ty():  BOOLEAI; 

ASK  METHOD  Inaart(II  alas  :  REFEREICE); 

ASK  METHOD  Ra»>va(II  ala»  :  REFEREICE) ; 

ASK  METHOD  SizaC)  :  IITEGER; 

EID  OBJECT; 

SatCursor  ■ 

OBJECT 

ASK  METHOD  Craata(II  sat:  Sat); 

ASK  METHOD  FiratO:  REFEREICE; 

ASK  METHOD  lalulK):  BOOLEAI; 

ASK  METHOD  MoraO:  BOOLEAI; 

ASK  METHOD  laxtO:  REFEREICE; 

ASK  METHOD  Raw>vaAtO; 

ASK  METHOD  RatriaaaO :  REFEREICE; 

EID  OBJECT; 

Traa  ■ 

OBJECT 

ASK  METHOD  CraataInDatabaaadI  db  :  Databaaa); 
ASK  METHOD  laEqitjO:  BOOLEAI; 

EID  OBJECT; 
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Tr««Cursor  ■ 

OBJECT 

ASX  METHOD  AddChildCll  itaa  :  REFEREHCE); 

ASK  METHOD  Cr«at«(II  tr««:  Tr««); 

ASK  METHOD  FirstChildO :  REFEREHCE; 

ASK  METHOD  IsFiratSiblingO :  BOOLEAI; 

ASK  METHOD  IsLastSiblingO :  BOOLEAI; 

ASX  METHOD  IaL«af():  BOOLEAI; 

ASK  METHOD  IsRootC):  BOOLEAI; 

ASK  METHOD  Mor«():  BOOLEAI; 

ASK  METHOD  H•ztSibling() :  REFEREICE; 

ASK  METHOD  ParantC):  REFEREHCE; 

ASK  METHOD  PravSiblingO :  REFEREICE; 

ASK  METHOD  RotovaAtO; 

ASK  METHOD  RatriavaO:  REFEREICE; 

ASK  METHOD  RootC):  REFEREHCE; 

END  OBJECT; 

END  MODULE. 

List 

CreatelnDatabase:  Creates  a  Ust  in  the  specified  database. 

First:  Sets  the  cursor  at  the  first  element  of  the  list  and  returns  a  point- 
erto  the  element. 

Insert:  Inserts  the  passed  in  item  at  the  end  of  the  list. 

InsertFirst:  Inserts  the  passed  in  item  at  the  front  of  the  list. 

Remove:  Removes  the  spedfied  item  from  the  list. 

RemoveFirst:  Removes  the  first  element  from  the  list. 

RemoveLast:  Removes  the  last  element  from  the  list. 

Size:  Returns  the  number  of  elements  in  the  list. 

ListCursor 

Create:  Creates  a  list  cursor  for  the  specified  list. 

InsertAfter:  Inserts  the  passed  in  object  after  the  current  element  in  the 

list. 

InsertBefore:  Inserts  the  passed  in  object  before  the  current  element  in 
the  list. 

IsNuU;  Returns  0  (false)  if  the  cursor  is  located  at  a  valid  element  of  the 
list;  returns  l(true)  otherwise. 
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Last:  Positions  the  cursor  at  the  last  element  of  the  list  and  returns  a 
pointer  to  the  element. 

More:  Returns  l(true)  if  the  cursor  is  not  at  the  last  element  of  the  list; 
returns  O(false)  otherwise. 

Next:  Advances  the  cursor  to  the  next  element  of  the  list  and  returns  a 
pointer  to  the  element. 

Previous:  Moves  the  cursor  to  the  previous  element  of  the  list  and  returns 
a  pointer  to  the  element. 

RemoveAt:  Removes  from  the  list  the  element  at  which  the  cursor  is 
currently  located. 

Retrieve:  Returns  a  pointer  to  the  element  of  the  list  at  which  the  cursor 
is  currently  located. 

PsirseLtst 

Append:  Appends  the  passed  in  list  to  the  end  of  the  target  list.  This  is 
done  by  physically  attaching  the  passed  in  list  to  the  end  of  the  target  list 
and  not  by  making  a  copy  of  the  passed  in  list.  Hence,  changes  made  to  one 
list  may  affect  the  other. 

Create:  Creates  a  Ust  in  the  specified  database  and  returns  a  pointer  to 
the  created  list. 

Insert:  Inserts  the  passed  in  item  at  the  end  of  the  list. 

InsertFirst:  Inserts  the  passed  in  item  at  the  front  of  the  list. 

Remove:  Removes  the  spedfied  item  from  the  list. 

RemoveFirst:  Removes  the  first  elonent  from  the  list. 

RemoveLast:  Removes  the  last  dement  from  the  list. 

PaneListCuraor 

Create:  Creates  a  parse  list  cursor  for  the  specified  list. 

First:  Sets  the  cursor  at  the  first  dement  of  the  list  and  returns  a  pointer 
to  the  dement. 

InsertAfter:  Inserts  the  passed  in  object  after  the  current  dement  in  the 
Ust. 

IsNull:  Returns  O(false)  if  the  cursor  is  located  at  a  vaUd  dement  of  the 
Ust;  returns  l(true)  otherwise. 

More:  Returns  l(true)  if  the  cursor  is  not  at  the  last  dement  of  the  Ust; 
returns  0(fal8e)  otherwise. 

Next:  Advances  the  cursor  to  the  next  dement  of  the  Ust  and  returns  a 
pdnter  to  the  dement. 

RemoveAt:  Removes  from  the  Ust  the  demec*  at  which  the  cursor  is 
currently  located. 
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Retrieve:  Returns  »  pointer  to  the  dement  of  the  list  nt  which  the  cursor 
is  currently  located. 

Tail:  Returns  the  tail  of  the  list  starting  from  the  current  location  oi  the 
cursor. 

Set 

Create:  Creates  a  set  in  the  specified  database  and  returns  a  pmnt^  to 
the  created  set. 

IsEmpty:  Returns  l(true)  if  the  set  is  empty  0(false)  otherwise. 

Insert:  Inserts  the  passed  in  itmn  into  the  set. 

Remove:  Removes  the  spedfied  item  from  the  set. 

Size:  Returns  the  number  of  cJmnents  in  the  set. 

SetCursor 

Create:  A  set  cursor  is  created  for  a  particular  set  which  is  specified 
when  the  set  cursor  is  created. 

First:  Sets  the  cursor  at  the  first  dement  of  the  set  and  returns  a  pcunter 
to  the  dement. 

IsNuU:  Returns  0( false)  if  the  cursor  is  located  at  a  valid  donent  of  the 
set;  returns  l(true)  otherwise. 

More:  Returns  l(trae)  if  the  cursor  is  not  at  the  last  dement  of  the  set; 
returns  0(fal8e)  otherwise. 

Next:  Advances  the  cursor  to  the  next  dement  of  the  set  and  returns  a 
pointer  to  the  element. 

RemoveAt:  Removes  from  the  set  the  dement  at  which  the  cursor  is 
currently  located. 

Retrieve:  Returns  a  pointer  to  the  dement  of  the  set  at  which  the  cv^r 
is  currently  located. 

IVee 

Create:  Creates  a  tree  in  the  specified  database,  with  the  object  pointed 
to  by  the  argument  root  as  the  root  of  the  tree.  Returns  a  pointer  to  the 
created  tree. 

IsEmpty:  Returns  l(true)  if  the  tree  is  empty;  returns  O(false)  otherwise. 

'nreeCursof 

AddChild:  Adds  the  passed  in  item  as  a  child  of  the  current  node. 

FirstChild:  Advances  the  cursor  to  the  first  child  of  the  current  node 
and  returns  a  pointer  to  the  object  stored  therdn. 

IsFirstSibling:  Returns  true  (1)  if  the  current  node  is  the  first  sibling, 
false  (0)  otherwise. 

IsLastSibling:  Returns  true  (1)  if  the  current  node  is  the  last  sibling, 
false  (0)  otherwise. 
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bLeaf:  Returns  true  (1)  if  the  curroit  node  b  a  leaf,  fabe  (0)  otherwise. 

bRoot:  Returns  true  (1)  if  the  current  node  u  the  root  of  the  tree,  false 
(0)  otherwise. 

NextSibling:  the  cursor  to  the  next  sibling  of  the  current  node,  if  any, 
and  returns  a  pointer  to  the  object  stored  therein. 

Parent:  Moves  the  cursor  to  the  psmnt  of  the  current  node  and  returns 
a  pointer  to  the  object  stored  therdn. 

PrevSibling:  Advances  the  cursor  to  the  previous  sibling  of  the  current 
node,  if  any,  and  returns  a  pointer  to  the  object  stored  therein. 

RemoveAt:  Removes  the  current  node  from  the  tree,  if  it  does  not  chil¬ 
dren.  Does  nothing  otherwise. 

Retrive:  Returns  a  pointer  to  the  object  stored  in  the  current  node  of 
the  tree. 

Root:  Sets  the  cursor  at  the  root  of  the  tree  and  returns  a  pointer  to  the 
element. 


B.5  Configurations 

The  Configuration  is  the  unit  of  version  contrd.  Instances  of  the  Configu¬ 
ration  class  provide  a  means  to  spedfy  groupings  of  objects  that  are  to  be 
treated  as  a  unit  for  version  control.  Object  instances  of  any  type  may  be 
aUocated  into  a  ^ven  Configuration.  This  includes  objects  of  type  Configu¬ 
ration,  thus  the  programmer  can  organize  subgroups  of  related  objects  with 
configurations  to  any  level.  Configuration  objects  are  the  unit  of  both  ver¬ 
sion  control  and  database  locking.  They  can  be  thought  of  as  long  duration 
transactions  on  the  database.  There  can  be  no  conflict  when  a  Configuration 
b  checked  out  to  a  given  application  as  other  applications  can  also  check 
out  versions  of  the  Configuration.  Configurations  provide  the  mechanism 
to  achieve  change  management  in  shared  environments.  Some  of  the  meth¬ 
ods  of  the  class  Configuration  include  check  out,  check  out  on  a  branch, 
and  check  in.  As  versions  of  a  configuration  are  checked  out,  changed,  and 
checked  back  in,  a  version  tree  is  formed  that  permits  users  to  go  back  to 
any  previous  version.  There  are  methods  for  traversing  the  version  tree  of 
a  particular  Configuration  object  to  retrieve  past  versions.  In  aU  of  the 
methods  of  the  Configuration  class  if  the  parameter  recursive  b  true,  the 
function  of  that  method  will  be  ^plied  to  all  subconfigurations  of  the  pven 
configuration.  Note  that  Configurations  must  be  used  within  the  context  of 
Workspaces. 
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DEFINITION  MODULE  Confisuration; 

FROM  Sagpant  IMPORT  Sagviant; 

FROM  Horkspac*  IMPORT  Horkspaca; 

FROM  Databasa  IMPORT  Databaaa: 

TYPE 

Configuration  ■ 

OBJECT 

ASK  METHOD  Craata  (IN  db:  Databasa; 

IN  naaa  :  ARRAY  OP  CHAR)  :  Configuration; 

ASK  METHOD  Chackin  (IN  db  :  Databasa; 

IN  nasa  :  ARRAY  OF  CHAR; 

IN  racursiva  :  BOOLEAN); 

ASK  METHOD  Chackout  (IN  db  :  Databaaa; 

IN  naaa  :  ARRAY  OF  CHAR; 

IN  racursiva  :  BOOLEAN); 

ASK  METHOD  ChackoutBranch  (IN  db  :  Databasa; 

IN  naaa  :  ARRAY  OF  CHAR; 

IN  branchNasa  :  ARRAY  OF  CHAR; 

IN  varsionNsM  :ARRAY  OF  CHAR; 

IN  racursiva  :  BOOLEAN); 

ASK  METHOD  Rasolva  (IN  itoa  :  REFERENCE; 

IN  nana  :  ARRAY  OF  CHAR) :  REFERENCE; 

ASK  METHOD  Lookup  (IN  db  :  Databasa; 

IN  naaa  :  ARRAY  OF  CHAR)  :  Configuration; 

ASK  METHOD  Marga  (IN  db  :  Databasa; 

IN  vs  :  Horkspaca; 

IN  naaa  :  ARRAY  OF  CHAR) ; 

ASK  METHOD  Succassor  (IN  db  :  Databasa; 

IN  naaa  :  ARRAY  OF  CHAR)  :  Configuration; 
ASK  METHOD  Pradacassor  (IN  db  :  Databasa; 

IN  naaa  :  ARRAY  OF  CHAR)  :  Configuration; 

END  OBJECT; 

END  MODULE. 
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Checkin:  Removes  the  current  version  of  the  configuration  from  the  cur¬ 
rent  workspace,  puts  it  in  the  parent  workspace,  freezes  it,  and  makes  it 
current  for  the  parent  on  the  branch  that  contains  it. 

Checkout:  Creates  a  new  version  of  the  configuration  and  inserts  it  into 
the  current  workspace.  If  the  parameter  recursive  is  true,  all  subconfigura¬ 
tions  of  the  configuration  are  checkout  as  well. 

CheckoutBranch:  Creates  a  new  ver^n  of  the  configuration  and  inserts 
it  into  the  current  workspace,  but  a  new  branch  will  be  created. 

Create:  Creates  a  configuration  in  the  specified  database.  This  creates 
a  branch  containing  the  newly  created  configuration.  This  initial  version  of 
the  configuration  is  set  to  the  default  for  the  current  workspace. 

Merge:  Checks  out  the  specified  configuration  and  calls  SetSuccessor  to 
set  it  to  the  new  version. 

Predecessor:  Returns  a  pointer  to  the  configuration  that  is  the  pre¬ 
decessor  of  the  current  configuration.  This  does  not  change  the  current 
configuration  in  the  workspace.  This  method  returns  false  if  there  is  no 
predecessor. 

Resolve:  Takes  a  pointer  to  an  object  in  one  version  of  a  configuration 
and  returns  a  pointer  to  the  corresponding  verdon  of  the  same  object  in 
another  version  of  the  configuration. 

Successor:  Returns  a  pointer  to  the  successor  of  the  specified  configura¬ 
tion. 


B.6  Workspaces 

The  Workspace  class  is  related  to  the  use  of  Configurations.  Workspace 
objects  provide  a  way  to  structure  shared  and  private  access  to  Configuration 
objects.  AU  manipulation  of  Configurations  most  take  place  within  a  current 
workspace.  Configurations  are  checked  in  and  out  of  workspaces.  Calls  to 
the  various  check  out  methods  of  Configuration  objects  are  relative  to  the 
current  workspace.  Workspace  objects  are  linked  (or  nested)  hierarchically 
into  a  workspace  tree.  Applications  can  set  the  access  privileges  to  parts 
of  this  workspace  tree  to  control  access  (and  hence  change).  There  is  must 
be  a  "global  workspace”.  Workspace  objects  are  then  allocated  within  the 
context  of  this  global  workspace.  Workspaces  combined  with  Configurations 
supply  the  needed  concepts  for  computer  supported  collaborative  work.  The 
Workspace  class  include  methods  to  create  child  workspaces  of  a  parent 
workspace,  to  get  the  parent  of  given  workspace,  and  to  set  a  Workspace 
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object  to  be  the  current  workspace. 


DEFIHITION  MODULE  Workspace; 

FROM  Database  IMPORT  Database: 

TYPE 

Workspace  « 

OBJECT 

ASK  METHOD  CreateGlobal  (IN  db  :  Database; 

IM  naae  :  ARRAY  OF  CHAR)  :  Workspace; 
ASK  METHOD  Create  (IH  db  :  Database; 

IH  naae  :  ARRAY  OF  CHAR; 

IM  parent  :  Workspace)  :  Workspace; 

ASK  METHOD  Resolve  (IM  db  :  Database; 

IM  name  :  ARRAY  OF  CHAR; 

IH  item  :  REFEREHCE)  :  REFEREMCE; 

ASK  METHOD  Lookup  (IM  db  :  Database; 

IM  pathname  :  ARRAY  OF  CHAR)  :  Workspace; 
ASK  METHOD  SetCurrent  (IM  vs  :  Workspace); 

ASK  METHOD  Current  ()  :  Workspace; 

ASK  METHOD  GetParent  ()  :  Workspace; 

ASK  METHOD  GetMame  (OUT  name  :  ARRAY  OF  CHAR) ; 

ASK  METHOD  Of  (IM  item  :  REFEREMCE)  :  Workspace; 

ASK  METHOD  Resolve  (IH  item  :  REFEREHCE):  REFEREMCE; 

END  OBJECT; 

EMD  NODULE. 

Create:  Creates  a  child  of  the  current  workspace  in  the  specified  database. 

This  new  child  workspace  can  be  referenced  by  the  specified  name. 

CreateGlobal:  Creates  a  global  workspace  in  the  specified  database  and 
with  the  spedfied  name.  This  is  the  root  workspace  from  which  all  child 
workspaces  are  rooted. 

Current:  Returns  a  pointer  to  the  current  workspace  object. 

GetName:  Returns  the  name  of  the  current  workspace. 

GetParent:  Returns  a  pointer  to  the  parent  workspace  of  the  current 
workspace.  This  method  does  not  make  the  parent  current. 
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Lookup:  Returns  a  pointer  to  the  serched  workspace  in  the  database. 

Of:  Returns  a  pointer  to  a  workspace  in  which  the  spedlied  object  re¬ 
sides. 

Resolve:  Returns  a  pointer  to  the  veruon  of  the  spediled  object  made 
visible  by  the  current  workspace. 

SetCurrent:  Sets  the  workspace  to  be  the  current  workspace.  Note,  this 
takes  effect  at  the  beginning  of  the  next  transaction. 

B.7  Segments 

Databases  are  composed  of  some  number  of  S^ments.  S^ments  can  be 
thought  of  as  the  smallest  unit  of  memory  that  is  transferred  from  persis¬ 
tent  to  transient  storage.  Every  database  is  created  with  an  initial  s^ment. 
As  objects  are  stored  in  the  database  additional  segments  are  created  au¬ 
tomatically.  The  Segment  dass  is  provided  as  a  means  of  dustering  groups 
of  objects  for  performance  reasons.  As  a  segment  is  the  unit  of  memory 
transfer,  significant  performance  improvements  can  be  gained  by  physically 
collocating  related  objects.  One  of  the  methods  of  the  Database  dass  is  the 
creation  of  Segments.  This  method  returns  a  Segment  object.  Methods  of 
the  Segment  dass  indude  those  to  determine  state  information,  control  size, 
and  destruction. 


DEFINITION  NODULE  Segnent; 


TYPE 

Segment  ■ 

OBJECT 

ASK  METHOD  CreateClN  db  :  Database)  :  Segment; 
ASK  METHOD  DatabaseOfO  :  Database; 

ASK  METHOD  DestroyC); 

ASK  METHOD  Of (IN  item  :  REFERENCE)  :  Segment; 
END  OBJECT; 


END  NODULE. 

Create:  Returns  a  pmnter  to  the  newly  created  s^ment  in  the  specified 
database. 
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DatabaseOf:  Returns  a  pointer  to  the  Database  object  containing  this 
segment. 

Destroy:  Deletes  this  segment  from  the  database. 

Of:  Returns  a  pointer  to  the  segment  object  containing  the  specified 
object. 
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Appendix  C 

Software  Engineering 
Classes 


This  appendix  provides  a  listing  of  C++  header  files  describing  the  classes 
that  make  up  a  persistent  object  framework  used  to  model  the  Import 
language.  This  model  is  called  an  intermediate  representation.  We  refer 
to  these  classes  as  Software  Engineering  Environment  Classes  because  they 
provide  the  basis  for  implementation  of  the  language  and  its  support  tools. 
These  classe  are  used  in  conjunction  with  Yacc++  [29]  and  the  Good 
interface  (see  Appendix  ??)  to  implement  an  object  repository  for  Import 
programs.  Yacc++  is  used  to  build  the  lexer  and  parser.  The  classes, 
through  the  Good  interface,  provide  for  persistent  storage  and  manipulation 
of  Import  compilation  artifacts. 

The  following  header  files  are  displayed  below:  id-seec.h,  id-type_expr.h, 
idjsymtab.h  and  i^emantics.h.  The  id-seec.h  file  defines  the  Import/Dome 
software  engineering  environment  support  classes.  These  classes  provide  a 
model  of  the  basic  features  of  the  language:  the  module,  class,  method  and 
the  declaration.  Also  contained  in  this  file  are  the  abstract  syntax  node  (ast) 
and  ast  list  classes.  The  second  section  consists  of  the  id-type.expr.h  file. 
This  file  contains  the  typejexpression  class  and  its  assodated  list  class.  The 
symbol  table  (Symtab)  and  support  classes,  the  scope,  symtabjentry  and 
symtab-entry  Jist  are  shown  in  the  next  section.  Finally,  the  semantic  action 
controller  class,  id-semantic.contndlOT,  is  shown.  This  class  implements  the 
semantics  of  the  language  and  calls  to  methods  of  this  class  are  triggered  by 
the  syntactic  states  determined  by  input  to  the  parser. 
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C.l  Software  Engineering  Environment  Classes 


/» Interface  for  the  ISLE  SEE  classes  used  to  represent  a  prt^ram  in 
an  OODB. 

#ifndef  ISEEC-H 
#deiine  ISEEC.H 
#mclude  <time.h> 

#iiiclude  <sys/stdtypes.h> 

#inclade  <id_oodb-externs.hh> 

#inclode  <id-oodb.hli> 

#mclude  <idjsymtab.h> 

#iiidude  <id.type-expr.b> 

#mdiide  <i-operator.h> 

dass  Dedaration  { 
public: 

scope  <t>local^cope; 

8yintab_entryJist  *deds; 
char  4<src.code; 

I*  Constructor  for  Declarations.  Ikkes  a  pointer  to  the  top  scope 

*  of  the  Module,  a  collection  of  declarations,  and  an  optional 

*  pointer  to  the  source  code,  if  it  is  decided  that  the  source  be 

*  needed  to  be  stored  in  some  manner. 

*/ 

Dedaratioii(scope  *ls,  symtabjentryJist  *d,  char  ♦sc  =  NULL); 
DedarationO; 

}; 


#defme  DEFINITION-MODULE  0 
#define  IMPLEMENTATION.MODULE  1 
#define  INTERFACE.MODULE  2 

dass  id-Module  { 
public: 


C2 


int  module-type; 
char  >»module-name; 
id-oodb-list  oid.Classes; 
id-oodb-list  4>imported-modttles; 

Declaration  *decl; 
long  last-touch; 
int  code-generation; 
int  hasjexternaLobj; 

I*  Constructor  for  Module.  The  type  nnd  name  of  the  module  must  be  specified 

*  Will  automatically  create  an  empty  collection  of  classes  smd  a 

*  declaration  object  with  the  scope  Is. 

*1 

id.Module(int  t,  char  4>mn,  scope  *ls  =  NULL,  int  eg  =  1); 

~id-Module(); 

}; 

class  id-Class  { 
public: 

symtab-entry  *se; 
symtab-entryJist  *super-classes; 
type-expressionJist  «stora^e-type; 
id-oodb-list  >t>methods; 
id-oodb-list  «teU-methods; 

Declaration  *decl; 

int  is-forward;  ^  is  it  a  forward  declaration?  */ 

int  is-external;  /» is  it  an  external  declaration?  */ 

id.oodb-list  ogknow;  /» class  knowledge  4/ 

/*  Constructor  for  id.Class.  Only  the  symbol  table  entry  need  be 

*  specified.  WiU  automatically  create  an  empty  collection  of  methods, 

*  and  declaration  object  with  scope  Is. 

V 

id-Class(symtabjentry  4iijBe,  symtabjentry-list  48c, 
type-expression-list  *st,  scope  ols,  int  is  J  =  0, 
id-oodb-list  ^gk  =  NULL); 

~id-Class(); 
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}; 

/»  Abstract  syntax  tree  */ 

class  ast Jist  :  public  id.oodbJi8t  { 
public: 

type-expression  Jist  *convert_to_type_expr-li8t(); 

}; 

class  ast-node  { 
public: 

oper  op;  /*  defined  in  oper.b 

astjQode  4>objJnstance;  /*  valid  only  for  method  invocations  *j 

symtab-entry  '^method;  f*  valid  only  for  method  invocations  */ 

type.expression-Ust  ♦wbich-type; 
union  { 
char  *s; 
int  i; 
float  f; 
char  c; 

astJist  *operand-list; 
symtabjentry  *se; 

}  semantic-value; 

/*  Discriminator  required  by  ObjectStore  */ 
int  discriminantO; 

/*  Constructors  for  astmode.  We  need  constructors  for  the  different 
*  types  in  the  union. 

V 

ast_node  (oper  i.op,  typejexpression-list  *wt); 
ast-node  (oper  i-op,  typejexpression-list  *wt,  char  *1-8); 
ast-Bode  (oper  i.op,  typejexpression.list  *wt,  int  iJ); 
ast-node  (oper  i-op,  type-expression.list  *wt,  float  1-f); 
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Mt-node  (oper  i^op,  typejexpression  Jist  *wt,  char  Lc); 
ast  Jiode  (oper  i.op,  typejexpresaon  Jist  *wt,  symtabjentry  *i^); 
ast-Dode  (oper  i-op,  typejexpressionJist  *wt,  astJiode  *objJ, 
syintab_entry  *in,  astJist  «ol); 
ast Jiode  (oper  Lop,  typejexpressionJist  *wt,  ast Jist  >»ol); 

'>-ast_node(); 

/»  deletes  the  type  expression  list  and  all  the  included  typejexpressions.  */ 
void  deLwhich-type(); 

/*  Stuff  required  by  ObjectStore 
private: 

int  os-discriminator.value; 
void  os^et.discriminator_value(); 


}; 

enum  method-types  {  M-NOT-METHOD,  M  JVSK,  M.TELL,  M.QUERY,  M.OPERATOR, 
M.CONSTRUCTOR,  M-DESTRUCTOR  }; 
typedef  enum  method.types  method-types; 

class  id-Method  { 
p'  ulic: 

symtab-entry  ■fse; 
method-types  method-type; 
type.expression  Jist  *parm.type; 
type.expression.list  *storage-type; 
symtabjentryJist  *parms; 
int  is.pnblic; 
symtab-entry  ♦of-dass; 
int  body-declared; 
ast.node  :»asf; 

Dedaration  *ded; 

/*  Constructor  for  Method.  Only  the  symbol  table  entry  need  be  specified. 

*  Will  automatically  create  an  empty  abstract  syntax  forest,  and  a 

*  declaration  object  with  the  srxtpe  Is.  */ 

id-Metbod(symtabjentry  *1-86,  method-types  mt,  type-expressionJist  *pt, 
typejexpression-list  *st,  symtabjentryJist  «fp,  int  p, 


/*  Entry  in  symbol  table  */ 


I*  Abstract  Syntax  Forest  */ 


C5 


symtabjentry  *oc^  int  bd  =  0,  astjiode  «a  =  NULL, 
scope  *ls  =  NULL); 

~id.Metbod(); 

}; 

#endif 

C.2  The  Type  Expression  Class 

/»  Class  defiattioB  for  the  typejexpression  class  used  by  the  symbol  table, 

*  and  for  static  semantic  checking.  Must  include  ’*idjoodb.b”  and 

*  ”id.oodb.externs.h”,  the  generic  object-oriented  database  interface 

*  before  including  this  hie. 

V 

#ifadef  TYPEJEXPRESSION.H 
#define  TYPE-EX  PRESSION.H 

#mdude  <id.oodb.exteTns.bb> 

^include  <td.ocdb.hb> 

extern  class  symtabjentry; 

ennm  atomic.type  {  T_NULL,  T-ENUM,  T.INT,  T.REAL,  TJBOOLEAN,  T.STRING, 
T.CHAR, 

T.ADDRESS,  TJIRRAY,  T.OBJECT,  T_LIST,  T.VARIABLE, 
T.PREDICATE,  T-ARTTHMETIC); 
typedef  ennm  atonuc.type  atonuc-type; 

class  type-expression  { 
pnblic: 

int  bnenumber; 
atomic-type  id-type; 
union  { 

int  size;  valid  only  for  arrays  </ 

symtabjentry  *id-clas8;  vaUd  only  of  objects  and  enum  types  */ 

}«; 
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I*  These  are  the  constructors  for  the  type^xpression.  */ 
type.expression(int  In,  atoinic.type  t); 
type-expression(int  In,  atomic.type  t,  int  8=:0); 
type_expression(int  In,  atomic-type  t,  symtabjentry  *8e=NULL); 

/*  Discriminntor  required  by  ObjectStore  *! 
int  discriminantO; 

/*  overloaded  operators  */ 

int  operator==(typejexpres8ion&  t); 

}; 

class  type-expressionJist  :  public  id.oodb.list  { 
public: 

I*  Given  that  tel  and  "this”  are  valid  type-expressionJists,  verifies 

*  that  tel  matches.  Returns  a  1  when  it  matches  and  a  0  when 

*  it  doesa ’t. 

*1 

int  compare.type(type.expressionJi8t  *tel); 

/«  Given  that  tel  is  a  valid  typejexpressionJist,  returns  a  copy 

*  of  it. 

V 

type-expressionJist  #makejcopy(typejexpre8sionJi8t  ^tel); 

/*  Given  that  tel  is  a  valid  typejexpressionJist,  appends  its  contents 

*  to  this  list.  The  original  list  is  unchanged. 

V 

type-expressionJist  *append(type.expre88ion-li8t  *tel); 

/*  Returns  the  only  type-expression  if  type-expressionJist  is  singleton, 

*  NULL  otherwise. 

*! 

type.expression  4>singleton(); 

f*  Returns  a  1  if  the  list  is  empty,  0  otherwise  4/ 
int  emptyO; 
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/»  Deletes  elements  of  the  list,  preserving  only  those  type-expressions 
*  whose  ntomic.type  is  t 

V 

void  de8troyjelemeiit8(atomic_type  t  =  T.OBJECT); 

/>  Prints  a  list  */ 
void  printf_elements(); 


}; 

#endif 


C.3  The  Symbol  T&ble  Class 

/»  Class  definition  for  the  symbol  table  object  and  related  sub-objects  used 
*  in  the  IMPORT/DOME  compiler. 

V 

#i£ndef  SYMTAB.H 
#defme  SYMTAB.H 

#indude  <id.type-expr.h> 
extern  class  ast  jtode; 
extern  class  ast^st; 
extern  class  Method; 
extern  class  id.Class; 

/*  Using  the  predifined  list  type  for  symtabjentryJist  and  block Jist.  *f 
class  symtabjentryJist  :  pnbhc  id.oodbJist  { 
public: 

/*  Compares  the  names  in  this  list  with  the  names  in  sel.  Returns  1  if 
*  they  are  the  same,  0  of  not. 

V 

int  compare_names(symtabjentryJi8t  *sd); 

/*  Deletes  the  elements  of  the  list  */ 
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void  destroy _elements(); 


f*  Prints  a  list  ♦/ 
void  printf.elementsO; 
}; 


/*  This  class  defines  a  scope  within  a  symboLtnble.  It  contains  a 

*  pointer  to  the  previous  scope,  the  current  scoping  depth,  and  a  local 

*  table  for  identifiers  declared  in  this  scope. 

V 

#define  SIZE.OFJSCOPE  53  /»  Hash  table  size  within  scope  *f 

class  scope  { 
public: 

scope  ^previous; 
int  depth; 

symtabjentryJist  *decls; 

symtab.entryJist  *locaL8ymtab[SIZ£.OF^COPE]; 

/*  Constructor  for  scope.  The  scope,  p,  is  the  previous  scope. 

*  The  new  scope  will  have  previous  point  to  p  and  depth  set  to 

*  p->depth  +  1. 

*/ 

scope(scope  *p); 

/*  Constructor  for  scope.  The  previous  pointer  and  depth  will  be 

*  set  to  0. 

V 

scopeO; 

/*  Prints  out  the  entries  in  the  scope.  */ 
void  printf.elementsO; 

/*  Destroys  the  symbol  tablejentries  associated  with  this  scope. 

*  Also  destroys  the  list  decls. 

V 
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void  destroy .elementsO; 

}; 


j*  TbJs  class  defines  a  symbol  table  entry,  consisting  the  name  as  seen 

*  in  the  source,  a  generated  name  that  is  used  in  the  C++  translation, 

*  a  type,  and  a  pointer  to  a  type  expresar^  or  *o  a  scope,  if  tbe  entry 

*  is  for  an  object.  Tbe  scope  type  is  used  as  a  convenience  for  semantic 

*  checking. 

V 

enum  symboLtypes  {  S.CONST,  S.TYPE,  S.VARIABLE,  S PARAMETER, 
S-CLASS, 

S31ETHOD,  S-DOME^YMBOL  }; 
typedef  enum  symboLtypes  symboLtypes; 
enum  parmJo.types  {  P-NOT-PARM,  PJN,  P.OUT,  PJNOUT}; 
typedef  enum  parmJo.types  parmJo.types; 

class  symtabjentry  { 


public: 

char  «symboljiame; 
char  >»generatedjiame; 
symboLtypes  symbol-type; 

astJist  *uscJist;  /*  contains  a  list  of  abstract  syntax 

*  trees  where  tbe  variable  appears.  */ 
int  mark;  /»  used  in  searching  *f 


union  { 

typejexpression  Jist  ^storageJype;  valid  for  variables,  methods, 

*  type  names  and  constants,  vj 
id.Class  ’^obj;  f*  valid  for  objects  (classes)  *j 

Method  ^method;  /*  valid  only  for  methods  */ 

} 


pann  Jo.types  parm  Jo-type;  /*  valid  only  for  parameters  */ 

ast-node  ^const-value;  /»  valid  only  for  constants 
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int  i8.public;  j*  valid  only  for  members  of  objects  </ 

int  iutatic;  /*  valid  for  external  C+j-  class  methods 

int  arity;  /» valid  only  for  dome  V 

int  is-prim;  /*  symbols  vf 

I*  These  are  the  constructors  for  the  symbol  table  entry.  The  generated 

*  name  is  created  by  this  method  bom  tlie  module  name  and  the  user’s 

*  symbol  name. 

V 

/>  Used  for  variables,  type  names,  formal  parameters.  *! 
8ymtabjentry(char  *8n,  8ymboLtyp«8  8t,  type-expressionJut  *8t.t, 
int  p=l,  pannJo-type8  pit=P.NOT^ARM); 

/«  Used  for  methods.  */ 

8ymtabjentry(char  >»8n,  Method  *m,  int  p=l); 

/<»  Used  for  constants  */ 

8ymtabjentry(char  «8n,  8ymboLtypes  st,  astjiode  «cv); 

/*  Used  for  classes  (objects)  vf 

syintabjentry(char  *sn,  8ymb<d.type8  et,  id-Class  *ijobj); 

/»  Used  for  imported  classes  and  types  */ 

8yintabjentry(char  «8n,  8yintabjentry  «ijeotry); 

/*  Used  for  dome  symbols  vj 
8ymtab^n  try  (char  4>8n,  int  ar,  int  ip); 

/»  Used  to  rename  a  generated  name  for  EXTERNAL  C++  calls 

*  needed  by  INTERTACE  MODULE 

V 

void  renaine^enQaine(char  *newgenname,  int  ujstat  =  0); 

/*  Discriminator  required  by  ObJectStore  4/ 
int  di8criininant(); 

}; 
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I*  This  class  implements  a  symbol  table  for  an  object-oriented,  lexically 
*  scoped  language. 

V 

class  Symtab  { 
public: 

scope  *cur^cope; 
scope  «cur-inodule; 
scope  4<globaLscope; 
symtabjentry  *curjobj; 

/*  Constructor  for  a  symbrd  table.  Sets  the  current  scope  to  the 

*  global  scope. 

V 

SymtabO; 

/*  Creates  a  new  scope  and  sets  the  current  scope  to  it.  */ 
void  enter  Jiew^copeO; 

/♦  Sets  the  current  scope  to  tie  scope  applicable  when  defining  methods 

*  of  a  class.  Returns  a  1  if  successful,  0  if  the  class  has  not  been 

*  defined  in  the  symbol  table. 

*  Exceptions:  Will  give  an  error  if  not  currently  in  the  module  scope. 

V 

int  enter-obj^cope(char  ^symbol); 

/*  Sets  the  current  scope  to  the  scope  that  was  surrounding  it. 

*  Exceptions:  Will  give  an  error  on  an  attempt  to  leave  a  global 

*  scope  or  when  the  previous  scope  was  NULL. 

V 

void  leave_scope(); 

/*  Inserts  a  local  or  member  variable  into  the  symbol  table  if  it 

*  does  not  already  exist.  If  it  already  exists,  it  returns 

*  a  NULL,  otherwise  it  returns  a  pointer  to  the  symtabjentry. 

V 

8ymtab.entry  *inseTt.var(ciar  ^symbol,  typejexpresuonJist  ♦t); 
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I*  Inserts  a  coastaat  into  the  symbol  tnble  if  it 

*  does  not  already  exist.  If  it  already  exists,  it  returns 

*  a  NULL,  otherwise  it  returns  a  pmnter  to  the  symtabjentry. 

V 

symtabjentry  *insert-coD8t(diar  ^symbol,  ast-node  *a); 

/*  Inserts  a  type  name  into  the  symbol  table  if  it 

*  does  not  already  exist.  If  it  already  exists,  it  returns 

*  a  NULL,  otherwise  it  returns  a  pointer  to  the  symtabjentry. 

V 

symtabjentry  <»insert-type(char  ^symbol,  typejexpressionJist  *t); 

/*  Inserts  an  class  name  into  the  module  scope;  creates  a  new 

*  scope  for  the  members  of  the  class  and  sets  the  current 

*  scope  to  it. 

*  Returns  a  NULL  if  the  class  already  exists,  or  if  not  in  the 

*  module  scope.  Returns  a  pointer  to  the  symtabjentry  otherwise. 

V 

symtab.entry  *insertjobj(char  <»symbd); 

I*  Inserts  a  method  name  into  the  symbol  table  under  the  current 

*  class  being  defined.  Parameters  are  the  name  of  the  method,  the 

*  Method  object  and  whether  the  method  is  public.  Returns  a  NULL  if 

*  the  symbol  is  already  defined.  Returns  the  symtabjentry  otherwise. 

V 

symtabjentry  *insert-method(char  ^symbol,  Method  *m,  int  p=l); 

/*  Inserts  an  imported  item  into  the  symbol  table  under  the  current 

*  module  being  defined.  Takes  the  name  of  the  item  in  this  module 

*  and  a  symbol  table  entry  from  the  imported  module.  Returns  the 

*  symtab  entry  created,  NULL  if  the  entry  already  exists. 

V 

symtabjentry  ^insert  Jmported(char  ^symbol,  symtabjentry  *imported_entry); 

/*  Inserts  a  dome  symbol  entry  into  the  current  scope.  */ 
symtabjentry  <»insert^omejBymbol(8ymtabjentTy  *se); 
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f*  Returas  a  pointer  to  a  tymbol  table  entiy  if  the  symbol  is  a 

*  method  or  a  field  in  the  object.  Returns  a  NULL  if  it  is  not 

*  found. 

V 

symtabjentry  *isJn-obj(char  Hymb<dt  symtabjentry  ^object jentry, 
int  *errjcode  =  NULL, 
type^expreceionJiit  ^pamJlist  =  NULL); 

/»  Returns  a  pointer  to  a  symbol  tnble  entry  if  the  symbol  is  a 

*  superclass  of  object.  Returns  a  NULL  if  it  is  not 

*  found. 

V 

symtabjentry  *is.ajBuperda88(char  *symbd,  symtabjentry  sobjectjentry); 


/*  Aeturns  a  pointer  to  the  symbol  table  entry  if  the  symbol  is 

*  defined  in  the  current  context.  Returns  a  NULL  if  it  is  not 

*  found. 

V 

symtabjentry  *isJn(char  ssymbdl); 

/*  Returns  a  pointer  to  the  symbol  table  entry  if  the  symbol  is 

*  defined  in  the  immediate  scope.  Returns  a  NULL  if  it  is  not 

*  found. 

V 

symtabjentry  «isJn Jocal(char  «symb<d); 

/*  Returns  a  pointer  to  the  symbrd  table  entry  if  the  symbol  is 

*  defined  in  the  outermost  (module)  context.  Returns  a  NULL  if  it 

*  is  not  found.  This  is  mainly  an  optimisation  feature;  classes 

*  can  only  be  defined  in  the  module  hvel,  and  if  we  are  looking  for 

*  a  class  definition,  it  can  only  be  at  the  module  level. 

V 

symtabjentry  ;»isJn-modnle(char  ssymbd); 

/*  Returns  a  pointer  to  the  symbol  table  entry  if  it  is  found  in  the 

*  scope  sc,  NULL  otherwise.  (CEB  must  check  parms  for  methods) 

V 
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symtab-entry  *isJi>jscope(char  *symbol,  scope  esc, 

typejexpressionJist  spanaJistsNULL  ); 

f*  Returns  a  pointer  to  the  symbol  tnble  entry  if  there  is  a  same 
*  mntcb.  Does  not  check  signeture.  Returns  NULL  if  no  match. 

V 

8ymtab_entry  «is_nameJnjBcope(char  ssymbol,  scope  *sc); 

}; 


extern  Symtab  osymboLtable,  4>lib^ymb<^table; 

#endif 

C.4  The  Semantic  Action  Controller  Class 

/*  Interface  for  the  semantics/object  builder  for  the  IMPORT  language  */ 

#ifhdef  SEMANTlCSJa 
#define  SEMANTICS^ 

#include  <id^eec.h> 

^include  <id_type_expr.b> 

#mdude  <idj5yintab.b> 

class  id^semantic-controUer  { 
public: 

Module  ^curanodule; 
pannJo-types  cur.parmJo-type; 
int  is_public; 
int  i8.overr.<dden; 

Module  .module; 

Method  *curjnethod; 
type.expression-list  scur.parm.type; 
symtabjentryJist  scur4>ana.i'.ame8; 
id.oodbJist  scurjuethods; 
id.oodbJist  scur.classes; 
id.oodbJist  scur.tdLmethods; 


♦> 


C15 


/*  Constructor  for  semaot/c  coatroUer  */ 
id-8emantic-controIler( ); 

I*  Imports  all  entries  in  the  Module  m  into  the  curjnoduJe.  If  m 

*  is  NULL,  has  no  effect. 

V 

void  iniport.Module(int  In,  Module  *m); 

/*  Builds  a  module  object  and  sets  the  curjnoduie  to  it.  Ikkes  a  module 

*  type  and  an  optional  local  scope.  A  new  scope  will  be  created  for  the 

*  module,  and  the  cur-scope  of  the  symboLtable  will  be  set  to  this.  The 

*  curjnaodule  of  the  symboLtable  will  also  be  set  to  this  scope  value. 

*  The  cur.module  of  the  semantic-cont  will  be  set  to  the  module  object. 

v 

void  build_Module(int  In,  int  t,  char  «mn,  scope  «ls  =  NULL); 

Builds  user  defined  types  and  stores  in  symbol  table 
*  Side  effect  is  that  it  destroys  iden. 

V 

void  build.user.type(int  In,  char  *  iden,  typejexpressionJist  *tel); 

/*  Builds  a  symtab  entry  for  the  variable  iden  of  type  te  and  inserts 

*  it  into  the  symbol  table. 

*  Side  effect:  frees  the  iden  string. 

V 

void  build_var(int  In,  char  *iden,  typejexpressionJist  *te); 

/*  Builds  a  symtab  entry  for  the  constant  with  value  v  and  inserts 

*  it  into  the  symbol  table. 

*  Side  effect:  frees  the  iden  string. 

V 

void  build-const(int  In,  char  «iden,  astjiode  ♦v); 

/*  Builds  a  singleton  type-expression  Jist  or  inserts  a  type.expression 

*  of  atomic-type  t  into  Ust  td.  s  is  the  optional  size  argument  in 

*  the  case  of  declaring  arrays.  Ur  is  the  line  number  of  the  declaration. 


C16 


*  The  second  version  is  for  classes,  c  is  the  class 

V 

type.expressioiiJist  *biuld-type(int  In,  atomic-type  t, 

type^expressionJist  «tel=NULL,  int  8=0); 

type-expressionJist  «baild-type(mt  In,  atomic-type  t,  symtabjentry  *c); 

f*  Determines  if  the  class  or  type  named  idea  exits,  and  if  so,  returns  its 

*  8torage.type. 

V 

type-expressionJist  «get.type(int  In,  char  *iden); 

/*  Builds  an  ast^ode  with  operator  op,  and  a  type-expression  with  atomic 
type 

*  a.  In  is  the  line  number  of  the  repression. 

V 

astjnode  «build-arith-ast(int  In,  oper  op,  atomic-type  a,  char  *datavalue); 
ast  jiode  4>bund.arith.ast(int  In,  oper  op,  atomic-type  a,  int  datavalue); 
ast-node  «build-arith.ast(int  In,  oper  op,  atomic-type  a,  float  datavalue); 
ast-node  *build-arith.ast(int  In,  oper  op,  atomic-type  a,  char  datavalue); 
ast-node  *bulld-arith-ast(int  In,  oper  op,  atomic-type  a, 
symtabjentry  *datavalue); 

/*  Builds  an  ast-node  with  operator  op,  and  operandJist  made  up  of  the 

*  operand.,. 

V 

ast-node  «build-unary^t(int  In,  oper  unary jop,  ast  jiode  ^operand); 
ast jiode  *build-arith^t(int  In,  oper  binary-op,  char  *stringjep, 
ast-node  «leftjoperand,  astjiode  *rightjoperand); 


/*  Builds  an  ast-node  for  an  identifier  (local  variable  or  object  member) 
*  as  a  location  for  data.  The  second  version  handles  array  references. 

V 

ast  Jiode  *build  Joc-ast(int  In,  char  Mtring.rep, 

symtab-entry  *inherited-class  =  NULL); 
ast-node  *buildJoc-ast(int  In,  ast.node  *base,  astjiode  4>index); 
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I*  Builds  ail  astjaode  for  aa  asaigamentjstatement  */ 

aat jiode  *build_assign^t(mt  In,  oper  assignjop,  char  *8tring.rep, 
astjDode  *loc,  astjiode  *expr); 

/*  Builds  an  astjaode  for  AND  and  OR  */ 

aat-node  «build.boolean_ast(uit  In,  oper  bodeanjop, 

ast jnode  *left joperand,  aat  jiode  «ri|pitjoperand); 

/*  BuiJds  an  ast^ode  for  relations  */ 

astjiode  *build j‘elationutft(int  In,  oper  reLop,  char  *8tringj«p, 
ast_node  <»leftjoperand,  aat^ode  *right^perand); 

/*  Builds  aa  ast^ode  for  statemeatJists.  Ifvis  NULL,  creates  a  new 

*  astMode,  otherwise,  it  adds  the  a8t_node  for  the  statement  s  to  the 

*  statement Jist  result  v. 

V 

ast^ode  4>buiId-8tmtJist(ast-node  *8,  astjaode  *v); 

/*  Builds  up  an  IF  statement  and  from  its  component  parts.  Ifvis  NULL, 

*  creates  a  new  astmode,  and  in  this  case,  opd  must  contain  the  astmode 
>  for  the  expression.  After  the  expression  is  inserted,  the  then  clause, 

*  and  the  elsif  clauses  must  be  inserted  in  order,  and  finally  the 

*  dse  clause. 

V 

ast-node  *build  Jf-stmt(int  In,  astmode  *opd,  astmode  *v); 

/*  Builds  an  elsif  clause.  </ 

ast-node  *build.elsif(int  In,  ast.node  *expr,  ast-node  *stmt); 

/*  Builds  an  else  clause  */ 
ast-node  «build-else(ast-node  *stmt); 

/*  Builds  a  return  statement,  the  expression  expr  is  optional.  */ 
ast-node  *build-retam(int  In,  astjiode  *expr  s  NULL); 

/*  Builds  a  while  statement.  */ 

ast-node  «build-whlle(int  In,  ast.node  *expr,  ast-node  *stmt); 
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f*  Builds  a  repeat  statement.  */ 

ast  jiode  obuild  j‘epeat(iiit  In,  ast^ode  *stnit,  aat  jiode  ♦expr); 

/*  Builds  a  loop  statement.  */ 
aitJiode  *build Joop(aBt jiode 

/»  Builds  an  exit  statement.  </ 
aatjiode  fbuUd.exitO; 

/*  Builds  an  bait  statement.  *! 
astjiode  4>build  Jialt(); 

/»  Builds  a  for  statement.  The  arguments  are  linenumber,  index 

*  variable,  initial  value,  Snal  value,  up  or  down  (up  =  1,  down  = 

*  0),  statement  list,  mid  optional  by  clause 

V 

astjiode  *build-for(int  In,  ast-node  *idx,  astjiode  *Lval, 
ast  jiode  *f.val,  int  up,  aat  jiode  ostmt, 
ast  Jiode  *byjexp  —  NULL); 

/*  Builds  up  an  CASE  statement  and  bom  its  component  parts.  If  v  is  NULL, 

*  creates  a  new  ast_node,  and  in  this  case,  opd  must  contain  the  astjuode 

*  for  the  expression.  After  the  expression  is  inserted,  the  WHEN  clauses, 

*  and  the  OTHERWISE  clause  must  be  inserted  in  order. 

V 

ast  Jiode  4>build_case(int  In,  aat  jiode  eopd,  astjiiode  ev); 

/*  Builds  the  WHEN  and  OTHERWISE  clauses  for  the  CASE  statement, 
cl  is 

*  the  case  label  for  the  WHEN  clause. 

V 

ast  jiode  *build_case.clause(oper  op,  ast  jiode  estmt,  ast-node  ed  =  NULL); 

/»  Builds  a  block  statement.  *! 
astjiode  ebuild-block(a8t  Jiode  estmt); 

/*  Builds  a  method  named  iden  as  a  member  of  the  current  object  */ 

Method  >i>bui]d.niethod(int  In,  char  eiden,  method-types  mt, 
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type.expres8ionJist  «retiini-type=NULL); 


f*  provides  for  renaming  of  external  C+-t-  methods  in  the  INTERFACE  mod¬ 
ule  */ 

void  rename.ext_method(int  In,  char  «iden,  char  ^newname,  int  is^tat  = 

0); 

/*  provides  for  renaming  of  external  C-h+  fields  in  the  INTERFACE  mod¬ 
ule  */ 

void  renaine_ext  Jield(int  In,  char  Mden,  char  «newname); 

/*  Builds  a  class  named  iden  and  sets  cur-obj  in  the  symbol  table  to 
*  the  new  id.class  obj  created. 

V 

id.class  <»build.class(int  In,  char  Md«>,  symtabjentryJist  ♦sc  =  NULL, 
int  isJ"  =  0); 


/*  Builds  a  list  of  symbol  table  entries  of  superclasses  of  a  class. 

*Ifvis  NULL,  creates  a  new  list  and  returns  the  new  list  as  the 

*  result. 

V 

8ymtab_entryJ[ist  ♦build.snperda88e8(int  In,  char  ♦superclassJd, 
symtabjentryJist*  v  =  NULL); 

/*  Sets  up  the  symbol  table  and  the  semantic  controller  for  parsing 

*  methods.  Handles  both  IMPLEMENTATION  and  INTERFACE  methods 

*  the  cname  paramater  is  for  renaming  DEFINITION  MODULE  class  names 

*  for  C+-f-  compatability. 

V 

void  setupjnethods(int  In,  int  mod.;  ype,  char  dden,  char  *cname=NULL); 

/*  Associates  an  method  body  with  the  prototype.  */ 
void  fillJn.method(Method  ♦m,  ast mode  ♦imsf); 

/♦  Builds  a  list  of  arguments.  Ifvis  NULL  creates  a  new  astJist 

*  and  inserts  the  first  aigmeat  and  returns  it.  Otherwise,  inserts 

*  the  arguments  in  v  and  returns  it. 
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V 

astJist  *bund-aTgJi8t(iiit  In,  aatjiode  *esxpr,  MtJist  *v); 


/*  Sets  up  the  inherited  class  variable  for  method  invoeatioBS.  */ 
symtab^ntry  «setupJiiherited(mt  In,  char  *inherited.dassJden): 

/*  Builds  a  method  invocation.  If  the  method  has  no  arguments  a  NULL 
*  is  given  as  the  argument  to  this  procedure. 

V 

ast  jiode  *build-methJnv(int  In,  char  einherited-daas, 
method.types  mt,  ast  jiode  eobjjexpr, 
char  vmethod^ame,  astJist  eargs  =  NULL); 

/*  Checks  that  a  method  invocation  is  a  valid  expresaon  </ 
v<ud  check-meth Jnv(int  In,  ast Jiode  emethJnv); 

/*  Builds  a  terminate  statement,  sj 
astjiode  «bui]d.terminate(); 

f*  Builds  an  INTERRUPT  clause  */ 
astJiode  «btti]d_onJntemipt(a8t_node  estmts); 

/*  Builds  WAIT  DURATION  statement  */ 
ast-node  «build_wait_dttr(int  In,  astjiode  eexpr,  astjiode  sstmts, 
ast jiode  ^intjclansesNULL); 

f*  Builds  WAIT  FOR  statement  4/ 

astJKode  *build-wait  Jor(int  In,  astjiode  eobjjexpr,  char  emethod-name, 
ast  Jist  *args,  ast  Jiode  ^atmts, 
ast jiode  vintjdanse  =  NULL, 
char  *inherited.clas8  =  NULL); 

/*  Builds  WAIT  FOR  TRIGGER  statement  V 
ast-node  ^build.wait  Jor.trigger(int  In,  ast-node  oobjjexpr, 
ast-node  *stmt8, 
ast-node  ^intxlanse  s  NULL); 
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/>  Biulds  iaterrupt  trigger  etetemeot 
Mtjiode  *buUdJaterrupt,tngger(int  In,  Mt_node  *objjBxpT, 
astjaode 

V 

/*  Builds  a  key  for  an  Mpplic^tha  </ 

void  baild-key(int  In,  char  «kiqrJBai&e,  char  »modolejame,  char  «claM-iiame, 
char  *niethod_name,  aatJist 


/»  Retrieves  a  deHaition  moduk  with  the  modnJejBame  and  return#  it. 

*  Jf  the  module  is  not  found,  NULL  is  returned. 

V 

Module  «retrieve_inodaIe(mt  In,  char  emodnle-name); 

/*  Sets  up  the  modules  »ad  for  import  </ 

void  8etup.buiIdjTnport(int  In,  char  *modnle_name); 

/*  Builds  symbol  table  entries  for  imp<Mrted  items  */ 

void  buildJinport(int  In,  char  *sourceJden,  char  etargetJden  s  NULL); 


/*  BUILT-IN  FUNCTIONS  */ 
aatjiode  4>bui]d.ab8(int  In,  oper  irjop,  aatjiode*  arg); 
a8t_Qode  *build_cap(int  In,  oper  charjop,  astjiode*  arg); 
ast  Jiode  *build_chart08tr(iat  In,  oper  diarjop,  art  Jiode#  arg); 
astjttode  <»bui]d_chr(int  In,  oper  intjop,  astJtode*  arg); 
astjiode  *build_float(int  In,  oper  intjop,  ast jiode*  arg); 
ast jiode  *build Jntto8tr(int  In,  oper  intjop,  ast Jiode#  arg); 
ast  jiode  «bui]d  Jower(int  In,  oper  strjdp,astjiode*  arg); 
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Mt  jiode  *build.max(mt  In,  oper  tcalnrjop,  att  jiode«  airg); 

ut  Jiode  *build.maxof(mt  In,  oper  Kale^,astJut*  arg); 

aatjiode  4>build-min(int  In,  oper  scalarjop,  a8t_node*  arg); 

astjtode  *build.nunoii(int  In,  oper  *cale^p,aatJiat*  arg); 

ast-node  *build.odd  (int  In,  oper  scalarjop,a8tjxode*  arg); 

ast_node  *build.ord(int  In,  oper  ordjop,astJiode«  arg); 

astjDode  *build.per8istent(int  In,  oper  op,a8tjDode*  arg); 

ast^ode  «build.po8ition(int  In,  oper  Btrjop,astjiode*  argl, 
ast_nodc*  arg2); 

astjiode  *build.realto8tr(int  In,  opo^  rjop,  astjiode*  arg); 

ast  jiode  *build.round(int  In,  oper  reaLx>p,  aatjDode*  arg); 

ast-node  «build.schar(int  In,  oper  8trjop,a8tjDode4>  argl, 
ast.node4>  arg2); 

ast-node  >t>id-seinantic-controller::bnild-simtime(int  In); 

ast-node  *build-strcat(int  In,  oper  op,ast-Iist*  arg); 

ast-node  *bui]d-strlen(int  In,  oper  strjop,  ast-node  *arg); 

ast-node  *build-strtoint(int  In,  oper  strjop,  ast.node*  arg); 

ast-node  4'bui]d-strtoreal(int  In,  oper  strjop,  ast.node4>  arg); 

astuiode  *build-substr(int  In,  oper  strjop,a8t.node*  argl, 
ast-nodeo  arg2,ast-node«  arg3); 

ast-node  *build.trunc(int  In,  oper  reaLop,ast  Jiode*  arg); 
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utjiode  *biiil(Liipper(int  In,  oper  str.op,  astjiode*  arg); 

ast_node  *hnild.val(int  In,  oper  ord.op,a8t_node«  argl,  ast-node*  arg2); 

/♦  BUILT-IN  rnOCEDURES  */ 

astjiodc  *hiiil(l.(loc(iiit  In,  oper  op,astjiode«  arg); 

aatjiodc  «l)Mil(l.dcc(int  In,  oper  op,astjiode*  argl,  astjiode*  arg2); 

astjnode  *l)nil(l.dispo8e(int  In,  oper  op,  astjiode*-  arg); 

astjnode  *buil(l.inc(int  In,  oper  op,aat-node«  arg); 

astjiode  «buil(Liiic(int  In,  oper  op,astjiode*  argl,  ast jiode«  arg2); 

astjiode  «btiil(l.input(int  In,  oper  8cale.op,  ast  Jist*  arg); 

astjiodc  «bnil(l.inscrt(int  In,  oper  8trjop,a8tJiode4'  argl, 
ast.iiodct  arg2,a8tjiode*  arg3); 

astjiode  *biiilcl_output(int  In,  oper  sca]e.op,  astJJst#  arg); 

/»  Builds  an  nst.node  for  making  a  persistent  object  *1 
ast_nodc  «biiil<l.piiew(int  In,  88t_node*  argl,  ast-node*  arg2, 
astJist*  args=NULL); 

astjtode  #birtl(l.roplace(int  In,  oper  str_op,a8tj)ode*  argl, 
ast.node*  arg2,ast_node«  arg3,astjiode*  arg4); 

astjiode  «biiil(l-strtocliar(int  In,  oper  op,astjiode«  argl,  astjiode«  arg2); 

/»  Builds  a/I  nst.node  for  making  a  transient  object  </ 
ast-node  «biiil(l.tnew(int  In,  aat jiode  *loc,  astJist  *args=NULL); 

/*  Builds  interrupt  statement  </ 

astJiodc  «bnil(l.ititorr(ipt(int  In,  oper  i-op,  astjiode  *obj-expr. 
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astjjode  «iiiethjiame); 


/*  END  BlUUhlNS  */ 
private: 

/♦  Interna/  error  printer  */ 
void  intornal.orror(iiit  code); 

/♦  5enian(/c  Error  Message  Printer  ♦/ 

void  semanl.ir.orror(int  lineno,  int  code,  char  ^message  =  NULL); 


); 


extern  id-scinanlic.coiitroUer  ♦semantic.cont; 
#endif 
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Appendix  D 

Generic  Object  Oriented 
Database  Interface 
Specification 


D.l  Introduction 

This  appendix  contsuns  the  C++  classes  dehning  the  Generic  Object-Oriented 
Database  (Good)  interface  developed  for  Import/Dome.  The  clases  listed 
here  constitnite  our  internal  rehMue  4.1  of  the  Good  interfsu:e.  The  Good 
was  developed  to  insulate  implementation  at  the  persistent  object  stor- 
^e  level  from  any  particular  database  and  to  premit  rapid  porting  of  Im- 
PORT/Dome  to  other  database  hosts.  This  interface  is  implemented  for 
ObjectStore  [7]  and  we  are  currently  developing  an  implementation  for  the 
DARPA  OpenDB  [37]. 

D.2  Database 

A  database  provides  a  way  to  manipulate  objects  in  persistent  storage  and 
is  organized  as  an  Unix-like  directory  hierachy.  All  persistent  objects  in  the 
database  must  have  a  named  entry-point  into  the  database  which  is  done  by 
DNEW  macro.  They  then  can  be  manipulated  through  the  directory  objects 
(see  directory  class  below)  where  they  reside.  An  open  count  is  maintsuned 
on  the  number  of  times  a  database  has  been  opened.  When  the  open  count 
is  decreased  to  0,  the  database  is  closed.  All  databases  are  automatically 
closed  when  the  program  terminates. 
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id_oodb_database::root-dir() 

id.oodb.directory  *root_dir(); 

Returns  a  pointer  to  the  root  directory  in  this  database. 

id-oodb_database:  :close(  ) 

void  close(); 

Decrements  the  open  count  by  one  if  the  resulting  open  count  is  greater  than 
one.  If  the  open  count  is  zero  the  database  is  closed.  If  called  from  within 
a  transaction,  the  above  does  not  take  place  until  the  end  of  th^  transaction. 

id-oodb_database::create(  ) 

static  id-oodb.database  ^create  (  char  ^pathname,  int  mode  =  0664, 
int  if.exists.overwrite  =  0); 

Creates  a  database  with  the  specified  path  name  and  mode.  The  database 
is  also  opened  for  reading  and  writing  and  its  open  count  is  incremented. 

id-oodb_database::get-path-name() 
char  *get.pathname()-, 

Returns  the  pathname  of  the  target  database. 

id_oodb_database::b-open() 

int  is.open(); 

Returns  l(true)  if  the  target  database  is  open,  O(false)  otherwise. 

id_oodb_database:  :is-writable() 

int  is_writable(); 

Returns  l(true)  if  the  database  is  writable  by  the  current  process.  Returns 
O(false)  if  the  database  has  been  opened  for  read-only  or  if  the  process  does 
not  have  write  permission. 

id-oodb_database:  :lookup(  ) 

static,  id.oodb.database  ^lookup  (const  char  ^pathname,  int  create Jiiode  = 

0); 

Returns  a  pointer  to  the  database  with  the  specified  pathname,  but  does 
not  open  it.  Returns  0  if  the  database  is  not  found. 

id_oodb_database:  :of(  ) 
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static  id-oodb.database  *of  (void  *item); 

Returns  a  pointer  to  the  database  in  which  the  object  item  resides. 

id-oodb-database:  :open(  ) 

void  open  (int  read-only); 

Increments  the  open  count  of  the  database  and  opens  it  for  the  specified 
access  type  -  read-only  if  l(true)  or  read- write  if  Of  false) 

static  id-Oodb-database  *open  (const  char  *path_name,  int  read-only  =  0); 
Increments  the  open  count  of  the  specified  database  “path-name”.  Sets 
up  the  access  type  specified  by  “read-only”  and  returns  a  pointer  to  that 
database. 

id_oodb-database::operator  ==() 
int  operator  ==(id-oodb-database  *that); 

Returns  l(true)  if  the  target  database  is  same  as  the  database  pointed  to 
by  “that”. 

id-oodb-database:  :alIow_externaLpointers(  ) 
void  allow. external-pointersf); 

Extend  the  validity  of  cross-database  pointers.  After  this  function  is  called, 
cross-database  pointers  can  be  stored  in  the  current  process  and  subsequent 
processes. 

id-oodb-database:  ’.destroy  (  ) 

void  destroy  (); 

Deletes  the  database  for  which  this  function  is  called.  Must  be  called  inside 
a  transaction. 

id_oodb-database::create-segmemt() 

id-oodb-segment  *create-segment(); 

Returns  a  pointer  to  the  newly  created  segment  in  the  specified  database. 
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D.3  Directory  j 

The  named  objects  in  a  database  are  organized  in  an  Unix-like  directory 
hierarchy.  A  directory  may  contain  other  directories  and  named  objects. 

The  default  working  directory  is  the  root  directory  (“/”)  which  is  created 

automatically  whenever  a  new  database  is  created.  Path  names  to  other  i 

directories  or  named  objects  are  specified  relative  to  the  current  working 
directory  or  by  using  the  complete  path  name  starting  with  the  root. 

id-oodb-directory :  :lookup(  ) 

static  void  ’^‘lookup  (id.oodb.database  "^db,  const  char  ’^path-name); 

Looks  up  a  named  object,  which  can  be  either  an  ordinary  object  or  a  di¬ 
rectory  object,  in  the  database.  A  pointer  to  the  object  is  returned. 

void  *lookup  (const  char  *objjQame); 

Looks  up  an  object  by  the  object’s  string  name  in  this  directory  and  returns 
a  pointer  to  that  object. 

id_oodb-directory::m8ert() 

static  void  insert  (const  char  *dir,  void  *item,  const  char  *name); 

Inserts  the  object  pointed  to  by  "item”  into  the  directory  ’’dir”,  with  the 
name  "name”. 

void  insert  (void  *item,  const  char  *obj_name); 

Inserts  the  object  pointed  to  by  item  into  this  directory  and  names  it  with 
the  specified  name  “obj.name”. 

id-Oodb-directory::l8() 

void  Is  (); 

Returns  a  list  containing  the  names  of  the  named  objects  and  subdirectories 
in  this  directory. 

id_oodb_directory :  :remove(  ) 
int  remove  (const  char  *obj_name); 

Removes  an  entry  for  a  named  object  “obj_name”  from  this  directory.  Does 
not  delete  the  object  from  the  database.  Returns  1  if  the  object  has  been 
removed  successfully,  else  0. 

id-oodb.directory :  :mkdir(  ) 
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id.oodb.directory  *mkdir  (const  char  *dir_iiame); 

Makes  a  new  subdirectory  “dir_name”  in  this  directory,  and  returns  a  pointer 
to  this  new  subdirectory. 

id-oodb_dir«ctory :  :r  mdir  (  ) 
int  rmdir  (const  char  ’^dirjiame); 

Removes  an  entry  for  a  named  subdirectory  “dir_name”  from  this  directory. 
Does  not  delete  the  subdirectory  from  the  database.  Returns  1  if  the  sub¬ 
directory  has  been  removed  successfully,  else  0. 

id-oodb-directory :  :getdir(  ) 

static  id-oodb-directory  *getdir  (id-oodb_database  *db,  const  char  *dir_name); 
Gets  a  directory  object  with  its  entry  name  “dir_name”  in  the  specified 
database.  Returns  a  pointer  to  the  directory  if  found,  else  returns  a  NULL 
pointer. 


D.4  Lists  and  Cursors 

D,4.1  List 

id.oodb_li8t :  :create() 

static  id_oodb-list  ^create  (id-oodb.database  ’^db); 

Creates  a  list  in  the  specified  database  and  returns  a  pointer  to  the  created 
list. 

static  id-oodbJist  ^create  (id-oodb.coniiguration  '*'conf); 

Creates  a  list  in  the  specified  configuration  and  returns  a  pointer  to  the 
created  Ust. 

id-oodb  Jist::insert() 
void  insert  (void  *item); 

Inserts  the  passed  in  item  at  the  end  of  the  list. 

id.oodb_list :  :iiisert_fint  (  ) 

void  insert-first  (void  *item); 

Inserts  the  passed  in  item  at  the  front  of  the  list. 
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id_oodb_list::remove()  | 

void  remove  (void  *item); 

Removes  the  specified  item  from  the  list. 

id_oodb_lbt::remove_fir8t() 

void  remove_first();  \ 

Removes  the  first  element  from  the  list. 

id-oodb-list::removeJast()  | 

void  remove Jast(); 

Removes  the  last  element  from  the  list. 

id-oodb.list :  :size(  ) 
int  size(); 

Returns  the  number  of  elements  in  the  list. 


D.4.2  List  Cursor 

A  list.cursor  is  created  for  a  particular  list  which  is  specified  when  the 
list.cursor  is  created. 

id_oodb_list-Cursor::first() 

void  *first(); 

Sets  the  cursor  at  the  first  element  of  the  list  and  returns  a  pointer  to  the 
element. 

id_oodb-list-cursor() 
id-oodbJist.cursor  (id_oodb_list  *list); 

Constructor  -  creates  a  list.cursor  for  the  specified  list. 

id-oodb-list-cursor :  :insert^fter(  ) 
void  *insert.after(void  *item); 

Inserts  the  passed  in  object  after  the  current  element  in  the  list. 

id-oodb_list-Cursor::insert-before() 
void  *insert_before(void  *item); 

Inserts  the  passed  in  object  before  the  current  element  in  the  list. 
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id_oodb_list_cursor::is-null() 

int  is_null(); 

Returns  O(false)  if  the  cursor  is  located  at  a  valid  element  of  the  list;  returns 
l(true)  otherwise. 

id_oodb_list-cursor::last() 
void  *last(); 

Positions  the  cursor  at  the  last  element  of  the  list  and  returns  a  pointer  to 
the  element. 

id_oodb_list_cursor::more() 

int  more(); 

Returns  l(true)  if  the  cursor  is  not  at  the  last  element  of  the  list;  returns 
O(false)  otherwise. 

id_oodb_list_cursor::next() 

void  *next(); 

Advances  the  cursor  to  the  next  element  of  the  list  and  returns  a  pointer  to 
the  element. 

id.oodb_list_cursor::previous() 

void  *previous(); 

Moves  the  cursor  to  the  previous  element  of  the  list  and  returns  a  pointer 
to  the  element. 

id_oodb-list_cursor::remove..At() 

void  remove_at(); 

Removes  from  the  list  the  element  at  which  the  cursor  is  currently  located. 

id.oodb_list_cursor::retrieve() 
void  *retrieve(); 

Returns  a  pointer  to  the  element  of  the  list  at  which  the  cursor  is  currently 
located. 
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D.4.3  Parse  List 


id-oodb.parseJist  ::append(  ) 

void  append  (idu)odb_parseJist  *1); 

Appends  the  passed  in  list  to  the  end  of  the  target  list.  This  is  done  by 
physically  attaching  the  passed  in  list  to  the  end  of  the  target  list  and  not 
by  making  a  copy  of  the  passed  in  list.  Hence,  changes  made  to  one  list  may 
aifect  the  other. 

id-oodb.psLTseJist :  :create(  ) 

static  id.oodb_parse_list  '^‘create  (id.oodb-database  ^db); 

Creates  a  list  in  the  specified  database  and  returns  a  pointe-  to  the  created 
list. 

id-oodb_pame-li8t::insert() 

void  insert  (void  *item); 

Inserts  the  passed  in  item  at  the  end  of  the  list. 

id-oodb.parse-list :  ’.insert -flrst(  ) 

void  insertJirst  (void  *item); 

Inserts  the  passed  in  item  at  the  front  of  the  list. 

id-fradb.psirse-list :  :remove(  ) 

void  remove  (void  *item); 

Removes  the  specified  item  from  the  list. 

id-oodb.parseJist :  :remove_first(  ) 

void  removeJirstO; 

Removes  the  first  element  from  the  list. 

id-oodb-parseJist :  :remove  Jast(  ) 

void  remove Jast(); 

Removes  the  last  element  from  the  list. 
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D.4.4  Parse  List  Cursor 


A  Ust-cursor  is  created  for  a  particular  list  which  is  specified  when  the 
list-Cursor  is  created. 

id_oodb_parseJist-cursor::fir8t() 

void  *first(); 

Sets  the  cursor  at  the  first  element  of  the  list  and  returns  a  pointer  to  the 
element. 

id.oodb.parse  Ji8t-cursor(  ) 

id_oodb_parse_list.cursor  (id_oodb_parse_list  *list); 

Constructor  -  creates  a  list-cursor  for  the  specified  list. 

id_oodb_par8eJist-cur8or::in8ert-after() 

void  insert_after(void  *item); 

Inserts  the  passed  in  object  after  the  current  element  in  the  list. 

id_oodb_par8eJbt_cur8or::i8-null() 

int  isjauUO; 

Returns  O(faise)  if  the  cursor  is  located  at  a  valid  element  of  the  list;  returns 
l(true)  otherwise. 

id-oodb.par8e  Ji8t-cur8or::more(  ) 

int  more(); 

Returns  l(true)  if  the  cursor  is  not  at  the  last  element  of  the  list;  returns 
O(false)  otherwise. 

id-oodb_par8e_list-cur8or::next() 
void  *next(); 

Advances  the  cursor  to  the  next  element  of  the  list  and  returns  a  pointer  to 
the  element. 

id.oodb.parse  Jist_cursor::reinovejat() 
void  remove_at(); 

Removes  from  the  list  the  element  at  which  the  cursor  is  currently  located. 

id.oodb.parse  Jist. cursor :  :retrieve(  ) 
void  *retrieve(); 


D9 


Returns  a  pointer  to  the  element  of  the  list  at  which  the  cursor  is  currently 
located. 


id-oodb.parseJist-cursor :  :tail(  ) 

id.oodb.parseJist  *tail(); 

Returns  the  tail  of  the  list  starting  from  the  current  location  of  the  cursor. 


D.4.5  Set 
id-oodb_8et::create() 

static  id-oodb_set  *create  (id_oodb_database  *db); 

Creates  a  set  in  the  specified  database  and  returns  a  pointer  to  the  created 
set. 

static  id_oodb_set  *c'-eate  (id_oodb_configuration  *conf); 

Creates  a  set  in  the  specified  configuration  and  returns  a  pointer  to  the  cre¬ 
ated  set. 

id-oodb_8et :  :i8-empty  (  ) 

int  is_empty  (); 

Returns  l(true)  if  the  set  is  empty  O(faise)  otherwise. 

id-oodb_set  ::insert(  ) 
void  insert  (void  *item); 

Inserts  the  passed  in  item  into  the  set. 

id-oodb_set :  :remove(  ) 
void  remove(void  *item); 

Removes  the  specified  item  from  the  set. 

id_oodb-set :  :size(  ) 

int  size(); 

Returns  the  number  of  elements  in  the  set. 
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D.4.6  Set  Cursor 


A  set_cursor  is  created  for  a  particular  set  which  is  specified  when  the 
set_cursor  is  created. 

id-oodb-set-cursor::first(  ) 

void  *first(); 

Sets  the  cursor  at  the  first  element  of  the  set  and  returns  a  pointer  to  the 
element. 

id-oodb-set_cursor() 

id-oodbjset.cursor  (id_oodb_set  *set); 

Constructor  -  creates  a  set_cursor  for  the  specified  set. 

id-Oodb_set_cursor::is-nuU() 

int  is_null(); 

Returns  O(false)  if  the  cursor  is  located  at  a  valid  element  of  the  set;  returns 
l(true)  otherwise. 

id-oodb_8et-cursor::more() 

int  more(); 

Returns  l(true)  if  the  cursor  is  not  at  the  last  element  of  the  set;  returns 
O(faJse)  otherwise. 

id_oodb_set-cursor::next() 

void  *next(); 

Advances  the  cursor  to  the  next  element  of  the  set  and  returns  a  pointer  to 
the  element. 

id-oodb_set  .cursor :  :remove.At  0 

void  remove.at(); 

Removes  from  the  set  the  element  at  which  the  cursor  is  currently  located. 

id-oodb_set_cursor::retrieve() 
void  *retrieve(); 

Returns  a  pointer  to  the  element  of  the  set  at  which  the  cursor  is  currently 
located. 
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D.4.7  Tree 


id-oo<lb_tree:  :create(  ) 

static  id-oodb-tree  *create  (id.oodb.database  *db,  void  *root); 

Creates  a  tree  in  the  specified  database,  with  the  object  pointed  to  by  the 
argument  root  as  the  root  of  the  tree.  Returns  a  pointer  to  the  created  tree. 

id-oodb_tree:  :is_enipty  (  ) 

void  is_empty  (); 

Returns  l(true)  if  the  tree  is  empty;  returns  O(false)  otherwise. 


D.4.8  Tree  Cursor 

A  tree.cursor  is  created  for  a  particular  tree  which  is  specified  when  the 
tree-cursor  is  created. 

id-oodb_tree-cursor::add.child() 
void  add-child(void  *item); 

Adds  the  passed  in  item  as  a  child  of  the  current  node. 

id.oodb-tree-Cursor::flrst_child() 

void  *first-child(); 

Advances  the  cursor  to  the  first  child  of  the  current  node  and  returns  a 
pointer  to  the  object  stored  therein. 

id_oodb_tree_cursor(  ) 
id-oodb_tree_cursor  (id.oodb.tree  *tree); 

Constructor  -  creates  a  tree.cursor  for  the  specified  tree. 

id-oodb_tree-cursor::is_first-sibling() 

int  is_first_sibUng(); 

Returns  true  (1)  if  the  current  node  is  the  first  sibling,  false  (0)  otherwise. 

id-oodb_tree-cursor::isJa8t-sibIing() 

int  isJast..sibling(); 

Returns  true  ( 1 )  if  the  current  node  is  the  last  sibling,  false  (0)  otherwise. 
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id-oodb_tree-cursor::uJeaf() 

int  isJeaf(); 

Returns  true  (1)  if  the  current  node  is  a  leaf,  false  (0)  otherwise. 

id.oodb-tree-cursor::ia-root() 

int  is_root(); 

Returns  true  (1)  if  the  current  node  is  the  root  of  the  tree,  false  (0)  otherwise. 

id.oodb-tree_cur8or::next-sibling() 

void  *next3ibling(); 

Advances  the  cursor  to  the  next  sibling  of  the  current  node,  if  any,  and  re¬ 
turns  a  pointer  to  the  object  stored  therein. 

id-oodb.tree-cursor :  :parent(  ) 

void  *pMent(); 

Moves  the  cursor  to  the  parent  of  the  current  node  and  returns  a  pointer  to 
the  object  stored  therein. 

id-oodb_tree-cur8or::prevjibUng() 
void  *pTev^ibUng(); 

Advances  the  cursor  to  the  previous  sibling  of  the  current  node,  if  any,  and 
returns  a  pointer  to  the  object  stored  therein. 

id-oodb-tree-cursor :  :remove  jat  () 

void  removejit(); 

Removes  the  current  node  from  the  tree,  if  it  does  not  have  any  children. 
Does  nothing  otherwise. 

id.oodb-tree-cursor:  :root() 
void  *root(); 

Sets  the  cursor  at  the  root  of  the  tree  and  returns  a  pointer  to  the  element. 

id-Oodb-tree.cur8or::retrieve() 
void  *retrieve(); 

Returns  a  pointer  to  the  object  stored  in  the  current  node  of  the  tree. 


D.5  Workspace 

id-oodb- workspace:  :create(  ) 

static  id-oodb-workspace  *create(id_oodb_database  *db,  const  char  *name, 
id-oodb.workspace  *parent=0); 

Constructs  a  workspace  called  “name“,  which  can  not  be  omitted,  with  the 
specified  parent  “parent”.  If  no  parent  is  specified,  the  new  workspace  is 
made  a  child  of  the  current  workspace.  Returns  a  pointer  to  the  created 
workspace. 

id-oodb- workspace:  :id^odb-Workspace(  ) 

id_oodb_workspace(id_oodb_database  *db,  const  char  *name,  id.oodb.workspace 
*parent=0); 

This  constructor  is  essentially  the  same  as  id-oodb-workspace::create().  It 
constructs  a  workspace  called  “name”  with  the  specified  parent  “parent”  in 
the  specified  database  “db”.  If  no  parent  is  specified,  the  new  workspace  is 
made  a  child  of  the  current  workspace. 

id-oodb.  workspace:  :create^lobal(  ) 

static  id.oodb.workspace  *create.global(id-oodb.database  *db,  const  char 
*name); 

Creates  a  global  workspace  with  the  specified  name  which  can  not  be  omit¬ 
ted  in  the  specified  database  “db”.  A  pointer  to  the  created  workspace  is 
returned. 

id-oodb_workspace::current() 

static  id.oodb.workspace  *current(); 

Returns  the  current  workspace,  which  is  the  workspace  on  which  the  most  re¬ 
cent  invocation  of  set.current()  has  been  made.  If  no  invocation  of  set.current 
has  been  made  in  the  current  process,  then  the  global  workspace  is  returned 
as  the  current  workspace. 

id_oodb_workspace::getjaame() 
const  char  *getjiame(); 

Returns  the  name  of  the  current  workspace. 

id-oodb_workspace::get_parent() 
id.oodb.workspace  *get.parent(); 

Returns  a  pointer  to  the  parent  workspace  of  the  current  workspace,  or  0  if 
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the  current  workspace  is  the  global  workspace. 

id-oodb_workspace:  :of(  ) 

static  id.oodb.workspace  *of(void  *item); 

Returns  a  pointer  to  the  workspace  that  maps  the  ob  ject  pointed  to  by  item. 
Returns  the  current  workspace  if  item  is  a  non  versioned  object. 

id-oodb-workspace::re8olve() 

void  *resolve(id.oodb_database  *db,  const  char  *path_name,  void  *item); 
Returns  a  pointer  to  the  version  of  the  object,  pointed  to  by  “item”,  which 
is  made  visible  by  the  specified  workspace  “pathjname”. 

void  *resolve(void  *item); 

Returns  a  pointer  to  the  version  of  the  object  that  is  made  visible  by  this 
workspace, 

id.oodb_workspace::set-current() 

static  void  set_current(id_oodb-workspace  *a-ws); 

Sets  the  workspace  “a-ws”  as  the  current  workspace.  This  action  takes  effect 
only  at  the  beginning  of  the  next  transaction. 

id.oodb.workspace:  :lookup() 

static  id.oodb.workspace  *lookup{id_oodb.database  *db,  const  char  *path  Jiame); 
Returns  a  pointer  to  the  workspace  “pathjiame”  in  the  specified  database 
“db”  if  it  is  found,  otherwise  returns  a  NULL  pointer. 


D.6  Configuration 

id.oodb.configuration::checkin() 

void  checkin  (id.oodb.database  *db,  const  char  *name,  int  recursive  =1); 
Removes  the  configuration  “name”  from  the  current  workspace  in  the  spec¬ 
ified  database  “db”,  freezes  it  and  inserts  it  in  the  parent  workspace.  The 
configuration  is  also  made  current  for  the  parent  on  the  branch  that  contains 
it. 


id-oodb-configuration::checkout() 


void  checkout  (id-oodb.database  *db,  const  char  *name,  int  recursive  =1); 
Creates  a  new  version  of  the  target  configuration  “name”  and  inserts  the 
new  version  into  the  current  workspace  with  write  access  in  the  specified 
database  “db”.  The  branch  containing  the  new  version  is  also  made  the 
current  branch. 

id-oodb-conflguration:  :checkout_br«iich(  ) 

void  checkout.branch(id.oodb.databa8e  *db,  const  char  '^name,  char  ^branch- 
name=0,  int  recursive=l); 

Creates  a  new  version  of  the  target  configuration  “name”  and  inserts  the  new 
version  into  the  current  workspace  with  write  access  in  the  specified  database 
“db”.  dike  checkout,  the  new  version  will  not  be  the  same  branch  as  the 
current  branch,  instead  it  will  be  an  alternative  version. 

id-oodb-configuration:  :create(  ) 

static  id-oodb_configuration  *create(id-Oodb.database  *db,  const  char  *name) 
Creates  a  configuration  called  “name”  in  the  specified  database  and  returns 
a  pointer  to  it. 

id.oodb.coiiflguraikin::merge(  ) 

void  merge  (id.oodb.databa8e  '''db,  id_oodb.workspace  *W8,  char  *name); 
Creates  a  new  version  of  the  target  configuration  and  makes  that  the  suc¬ 
cessor  of  the  target  configuration  and  the  configuration  “name”  which  is  in 
workspace  “ws”.  That  is,  this  function  merges  two  versions  of  configura¬ 
tions,  one  in  current  workspace  the  other  in  “ws”,  into  a  new  version  which 
is  the  successor  of  both  configurations. 

id_oodb-coiiflgur«tion::pr«decessor() 

id-oodb-configuration  *predece8Sor(id.oodb.database  *db,  const  char  *name); 
Returns  a  pointer  to  the  predecessor  version  of  the  target  configuration  and 
uses  the  predecessor  version. 

id_oodb-configuration::successors() 

id-oodbJist  *successor(id-oodb.database  '''db,  const  char  *name); 

Returns  a  pointer  to  the  successor  version  of  the  target  configuration  and 
uses  the  successor  version. 

id-oodb-conflguration:  :resolve(  ) 

void  ''‘resolve(id_oodb_database  *db,  const  char  ’^name); 
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Returns  the  version  of  the  object  “name”  that  is  mapped  by  the  target  con¬ 
figuration  in  the  specified  database  “name”. 


id-oodb-Configuratioii::lookup() 

static  id.oodb-configuration  *lookup(id_oodb_database  *db,  const  char  *name); 
Returns  a  pointer  which  points  to  configuration  “name”  in  the  specified 
database  “db”. 


D.7  Segment 

id_oodb_oodb-8egment::create(  ) 

id-oodb-segment  *create( const  id_oodb_database  *db); 

Creates  a  segment  in  the  specified  database  and  returns  a  pointer  to  the 
created  segment. 

id.oodb.oodb-segment :  :database-of(  ) 
id_oodb.database  *databasejof(); 

Returns  a  pointer  to  the  database  in  which  the  target  segment  resides. 

id-oodb-oodb-segment :  :dest  roy  (  ) 

void  destroyO; 

Deletes  the  target  segment  from  the  database.  This  results  in  the  destruc¬ 
tion  of  all  the  data  the  segment  contains.  This  action  cannot  be  undone  by 
aborting  the  transaction. 

id.oodb.oodb-segment :  :of(  ) 

static  id-oodb-segment  *of  (void  *item); 

Returns  a  pointer  to  the  segment  where  the  object  pointed  to  by  item  re¬ 
sides. 


D.8  Macro  Defines 

Several  macros  have  been  defined  to  ease  the  process  of  allocating  and  deallo¬ 
cating  objects  in  persistent  database.  These  macros  include  DNEW,  CNEW, 
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SNEW,  and  DELETE.  DNEW  is  used  for  allocating  objects  into  database, 

CNEW  is  specifically  used  for  allocating  objects  into  the  specified  configu¬ 
ration  in  the  database  for  versioning  purpose.  SNEW  is  used  for  allocating 
objects  into  the  specified  segment  for  clustering  purpose.  Delete  is  simply 
used  for  deleting  objects  in  the  database. 

ID_OODB-TXN.BEGIN,  ID.OODB.TXN.COMMIT,  and  ID.OODB.-TXN-ABORT 
are  transaction  related  macros.  The  first  macro  starts  a  transaction  and  con¬ 
trols  the  access  mode  provided  by  the  argument  read-only.  If  the  argument 
read-only  is  true  (1),  then  the  access  mode  is  read  only  otherwise  the  access 
mode  is  read-write.  The  second  one  signals  the  transaction  has  been  com¬ 
mitted  and  the  last  aborts  the  transaction. 

CNEW() 

CNEW(a_conf,type_name,num) 

Creates  an  array  of  “num”  number  of  persistent  instances  of  the  type  speci¬ 
fied  by  the  character  string  “type-name”,  in  the  configuration  pointed  to  by 
“a.conf”. 

DELETE 

Deletes  transient  or  persistent  instances. 

DNEW() 

DNEW(a_db,type_name,num) 

Creates  an  array  of  “num”  number  of  persistent  instances  of  the  type  spec¬ 
ified  by  the  character  string  “typejiame”,  in  the  database  pointed  to  by 
“a-db”. 

SNEW() 

SNEW(a_seg,type_name,num) 

Creates  an  array  of  “num”  number  of  persistent  instances  of  the  type  spec¬ 
ified  by  the  character  string  “type-name”,  in  the  segment  pointed  to  by 
“a_seg”. 

ID_OODB_TXN_BEGIN() 

ID-OODB-TXN.BEGIN(read.only) 

Begins  a  transaction  with  read-only  access  to  objects  if  l(true)  is  specified. 

If  O(false)  is  specified,  it  begins  a  transaction  with  write  access  allowed  to 
objects.  Nested  transactions  are  not  allowed  in  the  generic  interface. 
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ID-OODB.TXN.COMMIT 
Commits  the  current  transaction. 

ID_OODB_TXN_ABORT 
Aborts  the  current  transaction. 
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